Développement piloté par les tests et amélioration des compétences de test en boîte blanche

9

Je suis un programmeur Java d'entrée de gamme tout droit sorti de l'école. J'ai une bonne connaissance et expérience avec J2SE. Quelqu'un peut-il me conseiller sur la façon d'améliorer ou d'ajuster mes compétences pour devenir un testeur de boîte blanche Java? Une large gamme d'entrées est la bienvenue.

Et qu'est-ce que le développement piloté par les tests?

— user892871
source

Pourquoi pas les tests Black Box?

— Martijn Verburg

@Martijn, compte tenu de l'arrière-plan, probablement en raison des défis techniques des tests de la boîte blanche. De plus, bien que les techniques de boîte noire soient très utiles pour les développeurs, les personnes ayant de bonnes qualités pour un développeur ne font pas de bons testeurs de boîte noire, nous sommes trop curieux et pouvons devenir impatients. Je sais que je l'ai fait.

— StuperUser

9

Test Driven Development (TDD) et ses cousins étendus, Acceptance TDD (ATDD) et Behavior Driven Development (BDD) sont des techniques utiles pour apprendre en tant que testeur dans l'écosystème Java. Je vais me concentrer sur TDD lorsque vous recherchez des tests en boîte blanche.

Qu'est-ce que TDD? - Dans son cœur, c'est la pratique d'écrire un test qui échoue (en rouge), de faire passer ce test en écrivant une implémentation (en vert) puis de refactoriser. L' article Wikipédia est un endroit suffisant pour commencer à trouver de plus amples informations. Mais le sujet est vaste, je recommande de lire certains des livres bien connus dans cet espace tels que Test Driven Development by Example et Working efficacement with legacy code . Je vais également jeter un plug sans vergogne pour le chapitre TDD dans The Well-Grounded Java Developer

Dans l'écosystème Java, cela signifie que vous souhaitez apprendre:

La bibliothèque JUnit et / ou la bibliothèque TestNG .
Une bibliothèque moqueuse telle que Mockito ou JMock
Un outil de test de charge pour attaquer le code - JMeter
Le concept d' injection de dépendance (une forme d'inversion de contrôle)

Et puis pratiquez, pratiquez, pratiquez, pratiquez. Les bons testeurs de boîtes blanches Java sont très rares, les meilleurs ont des tests écrits sur une large gamme de bases de code.

HTH vous permet de commencer!

— Martijn Verburg
source

Ce sont également des techniques utiles pour apprendre en tant que développeur dans l'écosystème Java. Si je comprends bien, les testeurs devraient faire des tests en boîte noire.

— Tom

1

Junit est l'un des meilleurs frameworks de tests unitaires pour le langage de programmation Java. C'est un framework open source pour écrire et exécuter des tests reproductibles.

— Swagatika
source

1

Normalement, je n'aime pas citer Wikipedia, mais les informations sur cet article semblent assez sûres ...

http://en.wikipedia.org/wiki/Test-driven_development

En termes simples, il s'agit d'une approche Test-First pour le développement de logiciels où les tests unitaires sont conçus et écrits pour utiliser les cas en premier, puis un développement dur se produit ensuite pour aider à faire passer ces tests unitaires.

— maple_shaft
source

0

Je ne sais pas si ma suggestion sera considérée comme un outil pour les tests en boîte blanche, mais vous pouvez également consulter dbUnit pour les projets basés sur des bases de données et Selenium pour les tests Web (par exemple, inspection des éléments qui devraient exister sur la base de certains résultats).

— Bob Santos
source

0

La question fait spécifiquement référence aux "tests en boîte blanche". C'est là que vos tests ont une connaissance intime de la structure interne de votre code et affirment le comportement à chaque étape plutôt que juste l'effet d'entrée / sortie / effet secondaire (test de boîte noire). Bien que JUnit soit excellent pour faire les deux, vous avez besoin de cadres supplémentaires pour le faire dans le contexte d'un test unitaire.

EasyMock et JMock sont de bons cadres pour ce faire. J'ai tendance à favoriser JMock.

Au risque d'entamer un débat sur l'ergothérapie, vous devriez réfléchir attentivement aux implications des tests en boîte blanche. Les tests en boîte blanche sont intimement liés à votre code (évidemment), et s'ils ne sont pas utilisés avec précaution, les frameworks moqueurs peuvent rendre vos tests assez compliqués, difficiles à lire et ont tendance à être plus fragiles lors de la refactorisation.

J'ai tendance à m'en tenir à un mélange des deux. Tests de boîte noire dans la mesure du possible et tests de boîte blanche appliqués avec parcimonie au code plus risqué / plus compliqué.

Bien sûr, les cadres énumérés ci-dessus peuvent également être utilisés dans des tests de boîte noire où le nombre de classes contributives (injectées) est important et le stubbing simple devient difficile à gérer.

En ce qui concerne TDD - il s'agit principalement d'une approche d'amélioration de la conception de l'écriture de code, plutôt que d'une simple façon d'écrire des tests. Les tests que vous avez à la fin sont un résultat important, mais de plus, l'approche vise à améliorer la conception et la structure de votre application.

— rupjones
source