Exemple TDD pour les applications métier

Question

Je comprends l'idée générale des tests unitaires et je l'ai utilisée dans des scénarios où des interactions complexes se produisaient dans un système, mais j'ai toujours une question sur l'ensemble de ces principes.

Nous ne devons pas tester le framework ou la base de données. Une bonne conception de l'interface utilisateur ne se prête pas à des tests non humains. L'interaction de l'interface utilisateur en général est exclue dans les frameworks MVC. Dans de nombreuses applications, que reste-t-il? 37signals parle de tests unitaires approfondis, mais dans une application comme Basecamp ou Backpack, quels sont exactement les types de choses testées par des tests unitaires appropriés? Que signifierait une couverture à 100% dans ce scénario? EDIT: Je ne démonte pas des applications comme Backpack - elles sont géniales, mais le travail semble aller plus dans la conception et l'interaction au lieu de la logique complexe (en fait, ils épousent cette idée même). Dans les domaines de cette application, où le CRUD et la hiérarchie de l'objet sont liés à qui le recouvre à peu près, la quantité appropriée de tests unitaires est-elle nulle? Le point de test dans ce cas est-il une autre copie du code de validation (requis, regex, etc.)?

Answer 1

Le TDD pour applications professionnelles fonctionne de la manière suivante.

1. Notez vos besoins professionnels.

2. Notez un test pour cette exigence.

3. Écrire du code qui réussit le test.

L'astuce est qu'il existe de nombreuses exigences junky non-métier qui ne nécessitent pas de tests approfondis.

• «enregistre dans une base de données» n'est pas une exigence commerciale. C'est technique.

• "active un bouton sur l'interface graphique pour certaines situations" n'est pas une exigence de l'entreprise, il fait partie de l'interface.

• "sauvegarde" n'est pas une exigence de l'entreprise; c'est la sécurité ou la continuité des affaires ou quelque chose.

Considérons un exemple concret.

Exigence - «Vous ne pouvez pas emprunter de livres tant que vous n'avez pas payé vos amendes.

Tests.

1. Essayez d'emprunter un livre avec amende.

2. Essayez d'emprunter un livre sans payer d'amende.

Code.

class FinesNotPaid(unittest.TestCase): 
    def setUp(self): 
     # load some fixtures with users, books and fines outstanding. 
    def test_should_not_checkout_book(self): 
     x = TheCheckoutClass() 
     x.checkoutBook(someBook) 
     self.fail("Should have thrown error") 

class FinesPaid(unittest.TestCase): 
    def setUp(self): 
     # load some fixtures with users, books and fines paid. 
    def test_should_not_checkout_book(self): 
     x = TheCheckoutClass() 
     x.checkoutBook(someBook) 
     self.success() 

class NoFines(unittest.TestCase): 
    etc. 

Ce sont des règles métier implémentées par des classes distinctes de votre base de données et de votre interface graphique. Ce sont des classes dans une couche de domaine d'application. Vos règles CRUD sont règles commerciales. Vous devez les tester. Cependant, vous n'avez pas besoin de tester chaque fonctionnalité liée à la base de données. Vous avez besoin de quelques "puis-je créer et persister un objet?" tests. Vous devez avoir confiance que l'ORM, la couche d'accès aux données et la base de données fonctionnent réellement. Vous n'écrivez pas de tests pour tester de manière exhaustive les fonctionnalités intégrées de l'ORM.

La couverture de code (100% ou 80% ou 10%) est largement insignifiante. Un logiciel qui a des tests avec 80% de couverture de code est-il réellement 20% plus susceptible d'échouer? Cela ne fonctionne pas comme ça. Tester chaque ligne de code ne couvre pas tous les chemins logiques, alors arrêtez de vous inquiéter et commencez à tester.

Testez les cas d'utilisation professionnelle. Si elles passent et qu'il y a du code non testé, alors - peut-être - vous avez écrit trop de code.

Answer 2

Vous testez pour vous assurer que la logique métier (dans de nombreuses applications, il s'agit de la couche "service" ou "logique") correspond à la description de la façon dont l'entreprise fonctionne réellement. Vous testez pour vous assurer que, par exemple, parce que vous ajoutez 6% de taxe de vente à tous les achats de Pennsylvanie, vous ne donnez pas un bonus de 6% lorsque vous donnez une carte-cadeau à quelqu'un.

Il y a (ou il devrait y avoir) beaucoup de jus de cerveau dans les couches de l'application qui se situent entre l'interface utilisateur et la base de données. C'est le genre de choses à tester.