Can you really (unit) test with a RDBMS? What drive your application: data or tests? Who's your master?

2. DOJO (COMING SOON)
https://github.com/guillaumeagile/AtelierCleanArchitecture2013/
/c#/CLEAN-OneBrandTwoShopsTwoUI_WithTests

3. TESTING GOALS
1. Programmer errors
2. Design errors
3. Requirements errors
4. Systemic errors

4. http://www.qualitystreet.fr

5. UNIT OR NOT UNIT ?

6. PROGRAMMER ERRORS
Unit Tests guarantee safe Refactoring

7. DES TESTS RAPIDES
… ou rien !

8. ISOLATION
One thing at a time!

9. COMPLEXITY
In French : Combinatoire

10. LA COMBINATOIRE FAIT PEUR

11. INTEGRATION TESTS
5 composants qui ont chacun 50 cas de
fonctionnements
2 composants qui ont chacun 11 cas
différents

12. INTEGRATION TESTS

13. INTEGRATION TESTS

14. UNITAIREMENT
5 x 50 = 250
2 x 11 = 22
Total: 277 tests

15. REDUCE COMPLEXITY
Where does it come from?

16. FROM THIS?

17. OR THIS?

18. GRAVITY
Do you know
Newton?

19. A DATACENTRIC ARCHITECURE

20. DATABASE IS A

21. FROM THE CODE POINT OF VIEW
Database is a
Storage
Persitence
Service
Plug-in

22. THE DATABASE IS A
Detail !

23. MAKES YOU THINK TWICE
Which data to keep in your test and why?
Which data to keep in your code and why?

24. ISOLATE IT
I don’t care
I want objects
I want to code
I want an application
Test One Thing at a Time
Minimize Dependencies

25. CHANGE THE WAY YOU CODE

26. PATTERN 1: REMOVE THE CORE DATA
DEPENDENCE

27. ABSTRACT DATA TO A MODEL

28. REPOSITORY PATTERN
DB = persistence
No more!

29. PATTERN 2: CONSTRUCT AN IN-MEMORY CORE
DATA STACK.

30. MOCK IT, FAKE IT, DEFER IT
Find a gateway

32. MAKES YOUR LIFE EASIER
I must set up a Test DB
What if someone else add sh*t in your test DB?
Test DB is growing and growing…
What if you loose you DB connection?
What if you loose it all?

33. NO DEPENDENCE ON EXTERNAL STATE
• the tests must run the same
way every time they run

34. IDEMPOTENT TEST
you are able to rerun something because the process of
running it did not change its state.

35. CLOSE APPROXIMATION TO THE APPLICATION
ENVIRONMENT
With a Fake or a Mock

36. WHAT ABOUT CONSTRAINS
They are logic in data
They are impossible to test
They are hard to maintain

37. WHAT ABOUT TRANSACTIONS
Do you really need ACID ?

38. WHAT ABOUT STORED PROCEDURES
They are pain in the ass!
They embed logic with data
They are hard to test
They are hard to maintain

39. WHAT ABOUT TRIGGERS
They are evil

40. DID I SAY NO (TO) SQL?

41. CHANGE YOUR VIEW ON DATA
Is the DBA your master?

42. STOP DATA FASCISM
Stop thinking MDD (Model Driven Design)
MCD in French
Think DDD
DOMAIN
DRIVEN
DESIGN

43. FOCUSED INTEGRATION TESTS

44. EXPLORATORY TESTING

45. ONE BUG = ONE MISSING TEST
No unit test can tell you that you need more tests…
Exploration can.

46. THERE’S ALWAYS A PATTERN
To be more and more isolated (SRP/OCP/LSP/ISP/DI)
• Factory
• Facade
• Visitor
• IoC ( Depency Injectors)
• ….
• MVP
• Humble Dialog ….

47. ALL IS A MATTER OF CONCEPTS
Abstraction & Architecture

48. CHANGE THE WAY YOU CODE
ALWAYS CODE AS YOU TEST: in isolation
-> Domain knows nothing about the infrastructure.

49. CREDITS
http://visualstudiomagazine.com/articles/2009/09/01/eliminat
e-database-dependencies-in-test-driven-development.aspx
http://codebetter.com/jeremymiller/2005/10/12/unit-testing-
business-logic-without-tripping-over-the-database/
http://stackoverflow.com/questions/145131/whats-the-best-
strategy-for-unit-testing-database-driven-applications
http://www.jamesshore.com/Blog/Alternatives-to-Acceptance-
Testing.html
http://www.agiledata.org/essays/agileDataModeling.html
http://martinfowler.com/bliki/OrmHate.html
http://www.adam-
bien.com/roller/abien/entry/how_evil_are_actually_data