2009-08-15 5 views
1

Je vais faire une présentation sur les tests unitaires et, ce faisant, je vais aborder les modèles de «conception pour la testabilité». En d'autres termes, utiliser des conteneurs IOC, Dependency Injection, éviter les méthodes statiques, etc.Exemples physiques de conception pour la testabilité et le développement piloté par les tests

J'ai l'impression que mon équipe aura froid pour commencer à coder différemment pour s'adapter aux tests. Donc je me demandais si quelqu'un connaissait des exemples du monde réel d'altérer un design de quelque chose pour aucune autre raison alors pour le rendre plus facile à tester.
Je suppose que ce concept n'est pas rare dans la fabrication, l'ingénierie et d'autres professions, je ne suis pas familier avec des exemples concrets. J'imagine que le développement de la fusée Saturn V, de la navette spatiale, de l'automobile, de la robotique, etc. doit avoir un exemple documenté d'une certaine conception de testabilité ou peut-être de l'absence de problèmes.

Parmi les exemples viennent à l'esprit

  • Je suppose avoir des pièces remplaçables est une forme d'injection de dépendance, alors que le soudage de tous les composants ensemble ne permettrait pas à les tester individuellement.
  • Peut-être le port OBD2 sur les voitures modernes, car il est facile de vérifier si des systèmes ont des problèmes.
+0

Alors que certains des composants de la série Saturn ont été testées indivi dually et inclus dans le Saturn V, la configuration complète a été testée "tout en haut" (c.-à-d. tout à la fois): http://en.wikipedia.org/wiki/Saturn_V#C-5 – PTBNL

Répondre

1

De nombreux parasurtenseurs électriques ont un bouton de test pour vérifier la fonctionnalité correcte. C'est une forme de test très astucieuse, car ce n'est pas seulement entre les mains des développeurs, mais aussi des utilisateurs finaux. Autre exemple: de nombreux voyants de contrôle (en particulier dans les environnements critiques, comme les centrales nucléaires, etc.) ont un bouton pour les allumer et vérifier s'ils sont encore fonctionnels. La même chose pour de nombreux appareils utilisant des écrans LED.

Les piles disposent d'un indicateur d'alimentation, de sorte que vous pouvez les tester avant d'acheter. Dans le raffinage du sucre, vous surveillez de nombreuses étapes de la production (sorte de points de rupture) pour évaluer la qualité du produit. L'usine est conçue de manière à fournir ces points d'arrêt pour faciliter l'accès à un échantillonneur humain (normalement mal payé). Enfin, les constructeurs automobiles incluent tous les types de diagnostic. Un atelier de réparation automobile a un ordinateur pour effectuer une vérification complète de l'état de la voiture. C'est une sorte de journal de débogage "après le fait", donc pas vraiment "de test préventif", mais encore très utile et l'inclusion de celui-ci est un vrai "design de testabilité". La principale différence, cependant, entre les tests du monde réel et les tests du monde logiciel, est que les tests dans le monde réel peuvent ruiner le produit, à la limite d'être destructifs. Pour cette raison, le rapport défaut-bon est évalué par échantillonnage et analyse destructifs. Dans les tests de logiciels, vous n'avez jamais de tests destructifs (sauf si vous êtes un programmeur sadique avec de mauvaises intentions)

0

Si un ensemble de composants a été construit pour qu'ils puissent être testés, il est probable qu'ils seront plus modulaires et faiblement couplés. . Par exemple, il est plus facile de tester un code qui utilise un conteneur IOC plutôt qu'un localisateur de service car les collaborateurs peuvent être simplement moqués et injectés.

Cette séparation suit son développement. Comme le type n'a pas de dépendance forte vis-à-vis de ses collaborateurs, il permet la composition de ces parties dans une structure différente, ce qui signifie qu'il est plus simple de refactoriser/répondre aux nouvelles exigences.Vous aurez également plus de confiance dans tout refactoring car vous avez une suite de tests pour vérifier vos changements.

Pris ensemble, cela signifie dans mon expérience que le code écrit pour le test est plus rapide et plus facile à modifier, ce qui entraîne moins de travail pour moi, que j'aime.

Quelques exemples du monde réel des composants conçus pour les tests (eux-mêmes ou d'autres choses) pour éviter des problèmes plus bas de la ligne:

  • Détecteurs de fumée
  • disjoncteurs différentiels (dispositifs différentiels résiduels)
  • prévol contrôles du moteur dans l'aviation
  • Personal Breathalisers
Questions connexes