L'intégration continue doit toujours aller de pair avec le développement piloté par les tests?

Question

Je suis impliqué dans un projet où nous utilisons un serveur d'intégration continue et NUnit pour les tests unitaires et les tests d'intégration.

Un client nous a demandé l'autre jour si nous écrivions les tests avant le code ... Eh bien, ne le faisons pas toujours de cette façon. Surtout quand il y a des problèmes technologiques complexes que nous aimerions tester pour comprendre le problème et la solution possible en premier.

Je voudrais savoir si nous pouvions encore considérer notre processus de développement comme suit Agile Development, le dire aux clients et ne pas mentir.

Answer 1

Je pense que vous mélangez des choses ici. Test-Driven-Development (TDD) ne signifie pas nécessairement que vous utilisez une approche agile. Sûrement, c'est une bonne pratique que beaucoup d'entre nous qui agile utilisent, mais TDD peut également être utilisé dans un processus de cascade, remplaçant/complétant la spécification.

L'intégration continue en elle-même signifie que le code produit par votre équipe est intégré au moins une fois par jour. Cela ne force pas seulement tous les membres de l'équipe à fusionner/checker en continu, mais assure également que vous pouvez réellement faire une version de chaque build. Le processus de construction unifiée vous force à surmonter les "travaux sur mon syndrom machine". Parce que vous pourriez faire une sortie tous les jours cela supporte un processus agile, même si ce n'est pas absolument nécessaire au sens strict. L'utilisation de tests et leur intégration dans le processus de construction est un moyen d'enrichir votre processus de construction avec une assurance qualité automatisée et d'approfondir le niveau de test de l'intégration (intégrité).

Answer 2

Tant que vous développez en petites itérations, concentrez-vous sur l'obtention d'un produit fonctionnel plutôt que sur l'obtention d'une documentation complète, et le client est continuellement impliqué dans le projet, c'est un développement agile. Les tests unitaires, le TDD et les tests d'intégration sont bien sûr des bonnes pratiques et très recommandables, mais ils ne décident pas si votre projet est agile ou non.

Answer 3

En l'absence de tests automatisés, CI vérifie uniquement que le code sous contrôle de source est maintenu dans un état compilable entre les révisions et que la construction en une seule étape fonctionne correctement. Bien que ce soit utile, il n'est pas aussi utile que la vérification automatique que l'exactitude du code a été maintenue entre les révisions. Cela dit, je préférerais avoir une vérification de code entre les vérifications que rien. Je préfère avoir une couverture de code partielle ou un ensemble incomplet de tests fonctionnels que rien. Ou pire.