Le non unitaire du TDD

Le TDD s'associe souvent à des tests unitaires. Mais cela n'est pas toute la vérité et surtout cela a tendance à guider les gens dans une impasse.

Au delà des exemples basiques du TDD, regardons comment on s'y prend sur un vrai projet.

Difficile de développer une story en TDD? Les tests sont écrits après le code? Le code qui s'intègre avec d'autres systèmes est peu testé ou testé avec des mocks? Il y a beaucoup de tests à modifier pour refactorer du code? Voici quelques symptômes qui peuvent venir du même mal - une conception trop "unitaire" des tests et du TDD.

Certes, nous voulons des tests unitaires pour le besoin de reproductibilité, rapidité, maintenabilité etc. Mais ceci n'est ce qui nous importe lorsqu'on développe une nouvelle fonctionnalité où nous avons plutôt besoin de découvrir la réalité des choses, les problèmes d'intégration etc.

Comment allier les deux besoins? Que peut-on se permettre dans la phase de construction? Que fait-on avec les tests peu maintenables dans la CI? Les mocks, sont ils bien ou pas? Quels tests pour l'intégration avec "l'externe"? Puis-je faire avec mon projet "legacy"? Les réponses vous attendent dans cette session.

Transcript

1. The non-unitary in TDD TDD in presence of dependencies Johan Martinsson @johan_alps
2. The problem(s)
3. We don’t know how to test
4. We don’t know what to test
5. It's hard to mock
6. UNIT test don’t make sense
7. Surprises in integration • Rights not con fi gured • Heteregenous format, ex a date fi eld can have ddmm or dd/mm/yyyy • Apis lying about the information • Text recognition cuts things strangely • Performance in splitting a pdf • Rate limitation • Sending emails, is it well formed? Xavi cabrera Unsplash
8. Solutions!
9. No tests
10. Buy the tests
11. High level tests
12. Just write them!
13. Test last • When do they serve? • Who do they serve? • How do know if they’re good? Simon Berger Unsplash
14. My suggestion Start as early as possible
15. Example mapping
16. Start TDD with High level, integrated tests
17. How do we TDD this? What are the boundaries of the tests?
18. Result: Mockist style
19. Result: Classical style
20. In what order?
21. Inside Out
22. Outside In
23. Outside-In Classical TDD
24. Types of tests and qualities
27. The story of a story Find the position of a name in a pdf and if it is found, save it to the db. • Create a new lambda • Con fi gure lambda rights • Validate user rights • Extract data from request • Call external service • Parse result • If found, load existing data in db • Save data to db Etienne Girardet Unsplash
28. Example work fl ow • Write test agains deployed version • Validate function exists • Validate function does not fail • … • Write integrated test against version in IDE • Save hard-coded value to db • Deployed test validates function rights • Write another test • Call external service & parse result • More tests to vary input & expectations • Discover false assumptions • Isolate & refactor tests
29. Now Isolate
30. Architecture hexagonale
31. Dependency Adapter
32. Examples of adapters • Repository • Ex PersonRepository • File read/write wrapper • Message queue • External service wrapper • Ex Pdf extractor, email service …
33. Applicatio n test
34. Adapter Adapte r test
35. func TestExtractData(t *testing.T) { t.Skip("this costs 5 cts for each call, only activate when working on the adapter" ) client, err := newAdobeClient(t ) file, result, err := extract(t, "./Feuille_de_Presence_demembrement.pdf", client ) defer file.Close( ) assert.Nil(t, err ) assert.Len(t, result.Pages, 3 ) } Example expensive test
36. Example not isolating, yet // todo make this test faster (mocking ghostscript? ) func Test3Pages(t *testing.T) { testDir := findTestDir( ) service := createServiceWithFakeClient("analysis-result-2050-sd.json", testDir ) err, result := extractText(t, "2050-sd.pdf", testDir, service ) require.Nil(t, err ) require.NotEmpty(t, result ) }
37. Example switching back and forth //textractClient := realTextractClient( ) textractClient := plaquette.FakeTextractFromJson(baseDir + “analysis-result-2033.json" ) // … the rest of the tes t
38. Run the adapter tests for the simulators Real adapter Simulator Depend 
 ency Interface Test Flag for activation
39. Integrated tests in a CI?
41. Conclusion • Delay isolation • Delay low level tests • In a story • In a product • Separate integrated tests