Unit testing in python

motivation, techniques and tools

Transcript

1. Unit testing motivation, techniques and tools
2. Past •Tests were written after the code was “ready” •Mocks, Stubs, are also an old concept: isolate modules •Microsoft, Sun and other huge software companies were using since... ever
3. Hey wait... Microsoft Testing after written? +
4. coincidence?
5. Present •Kent Back changed the world •Google, Facebook, [your badass company here] doing •Mocks, Stubs, now are less heavily used
6. Why is it cool ? •Automagic refactoring •Modules are isolated •Code is cleaner •Modules are isolated •No more fear when changing code that is too important •They run just so fast •White box
7. Wait.... white box?!
8. White box •Comes from hacking/security vocabulary •The developer knows the codebase in depth •Test relies on internal calls
9. Test-driven development How to start it
10. Baby steps
11. Baby steps •Don’t write the whole thing at once •The next step will come naturally •Small units of code •The name is cute
12. The Mantra Red (1) Green (2) Refactor (3)
13. ... in other words
14. YAGNI YOU AIN’T GONNA NEED IT ...at least for now.
15. YAGNI
16. YAGNI Focus on what you need to achieve now don’t try to predict the future
17. Python Past/present/future?
18. Python - Past •unittest and unittest2 •class-based •camel case •overcomplicated •the community wasn’t really into it •... so we didn’t have many libraries BORING...
19. Python - Past
21. Python - Present •Nose — •DSLs are growing and becoming more popular •it is becoming fun to write tests •so that we’ll want to write more and more ROBUST CODE
22. Python - Present •Easier to write •conventions instead of classes •libraries leveraging mocks and stubs
23. Old-school mocking and asserting
24. But now we are hipsters
25. and cool libraries does the hard job
26. What about stubs? •They’re just like mocks •But doesn’t have behavior (no methods, just info)
27. What about stubs?
28. Future?!
29. Future?!
30. Future?!
31. Future?!
32. Django let’s have some fun
33. How it is •The default test support uses unittest2 •or doctests •don’t separate between unit, functional, etc •which leverages having very slow suites •doesn’t provide support for isolation •kinda focused on black box
34. Unclebob •per app tests (unit, functional, integration) •isolate the database so it fails if your test tries to use it •discover tests automagically
35. Unclebob http://bit.ly/woTgXq
36. testing huge views
39. the idea is simple
40. move logic into objects, testing each unit of logic separately
41. links •http://readthedocs.org/docs/nose/en/latest/ •http://github.com/gabrielfalcao/sure •http://github.com/gabrielfalcao/unclebob