[JAVA] Memo of JSUG Study Group 2018 Partie 2-Efforts pour les spécifications de travail à l'ère du printemps et de l'API-

introduction

C'est le dos du dépliant.

Modèle de programme de printemps et spécifications de travail-édition de test-

Matériel de présentation du premier M. Terashima ↓ Modèle de programme Spring et édition de test des spécifications de travail-

--Dans le test, écrivez à l'avance la condition (donner), l'opération (quand) et le résultat (alors).

Spock, une bibliothèque de tests écrite en Groovy, est pratique. ――Le test automatisé est positionné comme une spécification de travail.

Cas:

Le document de l'élément de test est compliqué et la procédure de gestion du drapeau n'est pas claire. Utilisez-vous manuellement la base de données et définissez-vous un indicateur?
Le contenu du test ne peut pas être déterminé à partir de la méthode de test. ↓ Définissez le nom de la méthode de test sur give-when-then.

La couverture des réunions n'est pas le but des tests! L'histoire du niveau de spécification est laissée sous forme de commentaire et il n'est pas nécessaire de spécifier (masquer) les méthodes d'opération non essentielles. La partie qui n'est pas liée aux spécifications est également transférée à partir du code produit (la classe Service est-elle une histoire qui se concentre sur le traitement métier?).

Avec le conteneur DI, il est devenu possible de résoudre des parties autres que le point de vue de test avec stub et simulacre.

Libération de la liaison de la classe parente de Framework --Résoudre les dépendances en injectant des dépendances

La maquette sera de plus en plus introduite dans la partie qui n'est pas le point de vue du test.

Test centré sur l'état Comment il a changé avant et après le test
Test centré sur l'interaction Quel type d'interaction est en cours

La pièce remplacée par une maquette est testée séparément et la hiérarchie est abaissée à un niveau qui ne peut pas être finalement remplacé par une maquette. Evidemment, c'est mal de se moquer de la méthode orientée test!

Il peut être appliqué du test E2E / test de scénario au test d'une méthode. Il faut faire attention à la granularité des spécifications. Il est important de tester l'utilisation de la cible de test = tester les spécifications.

En guise de mise en garde lors de l'écriture de la granularité, le drapeau de l'expression XX est programmatique et loin des affaires, utilisez donc le terme utilisé dans les affaires.

En fait, j'ai écrit un test manuel en interne avec donner-quand-alors.

Faites des tests, obtenez des preuves et enfin examinez. À partir de ce flux, j'ai pu revoir le type de test à faire à l'avance, donc les retouches sont réduites.
Sécurité psychologique car le programmeur comprend et procède au test. ――Il n'y a aucune différence dans la qualité des livrables simplement en modifiant la méthode de test.
Augmentation des coûts de création de documents.

Perspectives d'avenir Comment tester une énorme quantité de code produit. Aussi, afin de garantir la qualité, le refactoring est également coûteux.

――Je souhaite gérer de manière centralisée les spécifications de test dispersées. ――Je voudrais créer un exemple en utilisant les tests automatisés Spock et E2E. «Outre les approches telles que BDD et ATDD, il est essentiel que le code soit lisible.

Propositions et outils pour le développement de la vérification d'hypothèses dans l'édition API ère-API-

↓ Matériel de présentation de la deuxième personne, M. Otomori Propositions et outils pour le développement de la vérification d'hypothèses dans l'édition API ère-API-

Développement traditionnel: Au début, "Il y a une retouche si vous le vérifiez au stade de l'omission d'examen ou de mise en œuvre. Spécifications et" La gestion des versions de code est requise

Cas 1: Conçu et proto pendant six mois, puis développé pendant un an. Nécessite une coopération avec plusieurs fournisseurs. Chaque fournisseur a des propriétés différentes (s'il existe un document de conception, si la source peut être lue, etc.). Il est important à quel niveau la communication est possible entre la personne qui utilise l'API et la personne qui la crée. Document de conception, environnement, source (environnement: déployé et prêt à utiliser l'API).

Lorsque le fournisseur modifie la valeur de retour, la manière de coopérer est importante. Il peut y avoir un écart entre le document de conception fourni par le fournisseur et la source réelle.

Cas 2: Il est possible qu'un écart de reconnaissance se produise car il ne peut pas être expliqué en personne.

Par conséquent, le développement de la vérification d'hypothèse

-Votre demande est-elle correcte? -Est-ce que la spécification est correcte? -Est-ce que le livrable est correct?

Hypothèse, confirmation des entrées / sorties, mise en œuvre provisoire et développement principal. Outil pour vérifier chaque ↓.

Swagger Swagger peut être utilisé pour résoudre l'écart de taille de grain. Le créateur peut accéder à l'API simplement en écrivant yml avec l'éditeur Swagger. L'utilisateur n'a pas à regarder la source. Cependant, comme il n'est pas lié à la source, yml doit également être modifié si la source est modifiée.

SpringFox Les spécifications peuvent être générées à partir du code source. Les écarts de reconnaissance sont réduits car les spécifications peuvent être montrées à ceux qui utilisent l'API. Que vous puissiez ou non le frapper est une autre affaire.

Spring REST Docs Lorsque le test est exécuté, le document du test réussi est envoyé à AsciiDoc. Gradle peut également être utilisé pour le html et le pdf, éliminant ainsi l'écart entre le document et la source. Le document du test échoué n'est pas sorti, il ne remplace donc pas le document de conception.

Après tout, l'équilibre entre vitesse et granulométrie est important.