Notez les réflexions et les résultats basés sur les études de cas de tests automatisés. Les avantages à coûter et si c'est nécessaire en premier lieu sont des histoires différentes.
environnement | Contenu |
---|---|
OS | Linux |
Environnement de développement | Eclipse |
Dépôt | GitLab |
FW | SpringBoot |
FW | Junit |
Contenu de test automatique | résultat |
---|---|
la mise en oeuvre | 〇 |
indice | △ |
Continuer | × |
Il n'a pas été entretenu depuis environ six mois et cela n'a pas duré ... Le nombre d'étapes est plus grand que d'habitude, Je n'ai pas pu mesurer le résultat de l'introduction, alors je l'ai progressivement traité comme un bagage.
En raison du temps passé à mettre en œuvre des indicateurs de test et un traitement commun, l'introduction initiale a été un succès. ** C'est une erreur de penser que si l'introduction initiale se passe bien, le reste commencera tout seul. ** ** Lors de la réparation, il y a eu une omission de correction, elle a été reportée et c'est devenu une sensation subtile.
J'ai tendance à me concentrer sur le contenu du test, mais ** Je réalise que la chose la plus importante dans le processus d'introduction du TDD n'est pas le contenu mais le mécanisme ... **.
De plus, je pense que c'est un modèle d'échec que la plupart des gens connaissent **. ** ** Les indicateurs tels que la couverture et le traitement commun sont bons, mais ils semblent être à temps même après s'être habitués à eux. Le résultat de la réflexion sur le mécanisme sera écrit dans "Success Edition".
Présentation de TDD (succès) https://qiita.com/ilohas20983/items/365beea2756e00a7bfab