0

Dire que j'ai trois méthodes, très similaires, mais avec différents types d'entrée:les tests unitaires devraient-ils être des tests en boîte noire ou des tests en boîte blanche?

void printLargestNumber(int a, int b) { ... } 
void printLargestNumber(double a, double b) { ... } 
void printLargestNumber(String numberAsString, String numberAsString) { ... } 

Tous trois utilisent la même logique sous-jacente. Par exemple: peut-être la version double est la seule qui compare les nombres, et les deux autres convertissent simplement leurs entrées en double.

On pourrait imaginer quelques tests unitaires différents: la première entrée est plus grande, la deuxième est plus grande, les deux entrées sont négatives, etc.

Ma question

Si les trois méthodes ont l'ensemble des des tests (boîte noire puisque nous ne supposons pas la mise en œuvre de base est le même)

ou

Si seulement La version double sera testée fortement et les deux autres testées légèrement pour vérifier la conversion des paramètres (test en boîte blanche puisque nous savons qu'ils partagent la même implémentation et qu'il a déjà été testé dans les tests double)?

+0

Hrm ... cela pourrait être une dupe de http://stackoverflow.com/questions/203075/should-i-use-glass-box-testing-when-it-leads-to-fewer-tests –

Répondre

2

Si toutes ces méthodes sont publiques, c'est-à-dire appelables par le monde extérieur, je testerai certainement toutes ces méthodes avec un ensemble complet de tests. Une bonne raison est que les tests en boîte blanche sont plus fragiles que les tests en boîte noire; Si l'implémentation change, le contrat public peut changer pour certaines de ces méthodes.

2

Cela dépend.

Pensez-vous que la mise en œuvre est susceptible de changer? Si oui, faites un test de boîte noire.

Si vous pouvez garantir que la mise en œuvre ne changera pas avec la boîte blanche. Cependant, les chances de pouvoir garantir cela ne sont pas 100%.

Vous pourriez faire des compromis et effectuer certains des tests de boîte noire, en particulier autour des conditions aux limites. Cependant, écrire les tests devrait être facile - donc il n'y a aucune excuse de ce point de vue pour pas faire des tests de boîte noire complète. Le seul facteur limitant est le temps nécessaire pour exécuter les tests. Peut-être devriez-vous étudier la possibilité d'exécuter les tests en parallèle.

+0

+ 1 pour "écrire les tests devrait être facile".C'est vrai, ils seraient tous très similaires et faciles à écrire, et cela aiderait si l'implémentation change (ce qui est à quoi servent les tests!). Merci d'avoir répondu! –

+1

Vous ne pouvez pas garantir que l'implémentation ne changera jamais. Pas 50%, pas 20%, pas 1%. Tu ne peux pas. Tout peut changer à un moment donné. Et si vous testez seulement une partie de votre code "parce que je sais que c'est un alias", alors quand ça change (pas si, quand) vous avez soudainement (sans le savoir tout de suite) arrêter de tester une partie de votre code . Pas bon. Toujours supposer que tout peut, et la plupart * va * changer à un moment donné. Testez en conséquence. –

2

Il existe un ensemble de tests qui exercent explicitement les interfaces publiques. Je traiterais ceux-ci comme des tests en boîte noire.

Il existe un deuxième ensemble de tests qui peut être vu en regardant les cas de coin de l'implémentation. C'est un test en boîte blanche et il a sûrement sa place dans un test d'unité. Vous ne pouvez pas connaître les chemins intéressants sans une certaine connaissance de l'implémentation de la boîte blanche. Je porterais une attention particulière au cas de la corde, car l'interface permet des chaînes qui ne peuvent pas convertir proprement en doubles, qui repoussent les limites de la précision etc.

Est-ce que je couperais quelques coins dans le cas entier? Je sais que j'ai poussé les chemins dans le double cas, ne devrait probablement pas mais pourrait bien sous la pression du temps.

+0

bon point sur l'interface publique –