TDD Workshop

Some slides for a workshop I gave about Testing, Design Principles and TDD.

Transcript

1. Test Driven Development Juanjo Coello (juanjo@tuenti.com)
2. The Problem Software has unanticipated changes. Always.
3. The Problem Try to write a code which may be easily changed, extended (or dropped).
4. The Problem Can pick only two... FAST GOOD CHEAP
5. LIFE THOU ART UNFAIR!
6. Testing helps to... • Be a bit faster (in the mid/long term) • Be a bit cheaper (from minute 0) • Be a bit better (From minute 0)
7. FASTER
8. Time taken to fix bugs http://www.slideshare.net/Skud/test-driven-development-tutorial
9. CHEAPER
10. Time taken to fix bugs
11. Yes. It's repeated on purpose.
12. • The cost rises because of the technical debt • "We'll come back to fix this... eventually" • Testing helps to pay debt regularly. Cheaper
13. BETTER
14. Better • Testing usually implies less bugs • Less bugs implies better quality: the software work as expected. • Not easy to quantify, though.
15. Why do we write automated tests?
16. • Guard against regressions ◦ We can add new features without breaking existing ones • Gain confidence to change Automated Tests:
17. • Frequent manual testing is just impractical • Reduce the costs of building, deploying, and modifying versions of the system Automated Tests:
18. • Discover better designs ◦ We use the tests to clarify our ideas about what we want the code to do. Automated Tests: "When we find a feature that's difficult to test, we don't just ask ourselves how to test it, but also why is it difficult to test." Steve Freeman, Nat Pryce (Growing Object Oriented Software Guided by Tests - GOOS)
19. • Developers spend far more time reading code than writing it, so that’s what we should optimize for. • Simplicity takes effort. Automated Tests:
20. • Constantly refactor our code as we work with it ◦ To improve and simplify its design ◦ To remove duplication ◦ To ensure that it clearly expresses what it does • The test suites in the feedback loops protect us against our own mistakes as we improve the code. Automated Tests:
21. Test Driven Development
22. Testing THINK IMPLEMENT TEST
23. TDD THINK TEST IMPLEMENT
24. TDD THINK TEST IMPLEMENT
25. WRITE TEST TEST PASS TEST FAIL WRITE CODE THAT MAKES TEST PASS REFACTOR Feel da flow...
26. "We find that the effort of writing a test first also gives us rapid feedback about the quality of our design ideas - that making code accessible for testing often drives it towards being cleaner and more modular" Steve Freeman, Nat Pryce (GOOS)
27. Example (Groovy rocks)
28. Write once, run often. • Write tests once • Run frequently (it should be easy) • No human input • Machine-parsable output
29. Bug Fixing
30. Bug Fixing • Reproduce the error • Make a test that reproduces the error ◦ It should fail • Fix the bug ◦ Now the test should pass • Keep the test in your Test Suite.
31. Legacy Code
32. "Does anyone know what this does?"
34. "Do you know if there is any documentation related to this?"
36. Legacy Code • Legacy Code == Technical Debt • Try to improve it ◦ Document it ◦ Understand it ◦ Clean it up ◦ Refactor it
37. WTF!!! TEST PASS TEST FAIL AHMM REFACTOR
38. 1. Look at the code. Get scary. 2. Write a first test to see what happens 3. It usually fails 4. Refine it 5. Test passes 6. Grab another piece of code Legacy Code
40. Good Practices
41. S.O.L.I.D. PRINCIPLES • Single Responsibility • Open-Closed • Liskov Substitution • Interface Segregation • Dependency Inversion
42. Single Responsibility • Only one reason to change ◦ A single responsibility, and that responsibility entirely encapsulated. 1. "Our heuristic is that we should be able to describe what an object does without using any conjunctions ('and', 'or')" Steve freeman, Nat Pryce (GOOS)
43. Single Responsibility "An element’s cohesion is a measure of whether its responsibilities form a meaningful unit (...) a class that parses both dates and URLs is not coherent, because they are unrelated concepts. Think of a machine that washes both clothes and dishes—it’s unlikely to do both well." Steve freeman, Nat Pryce (GOOS)
44. Single Responsibility "At the other extreme, a class that parses only the punctuation in a URL is unlikely to be coherent, because it does not represent a whole concept. To get anything done, the programmer will have to find other parsers for protocol, host, resource, and so on. Features with “high” coherence are easier to maintain." Steve freeman, Nat Pryce (GOOS)
45. Single Responsibility • "Methods with no more than 5 lines of code, classes with no more than 3 public methods (average)." Carlos Blé
46. Open-Closed Principle • Software entities – classes, modules, functions and so on – should be open for extension but closed for modification.
47. Open-Closed Principle • It’s often better to make changes to things like classes by adding to or building on top of them (using mechanisms like subclassing or polymorphism) rather than modifying their code • In short: If it works, don't touch it" Carlos Blé
48. Liskov Substitution Principle "If it looks like a duck, swims like a duck, quacks like a duck but it needs batteries, you probably have the wrong abstraction"
49. Liskov Substitution Principle
50. Liskov Substitution Principle • Subclasses should be substitutable for the classes from which they were derived • "Don't abuse inheritance (are they really the same thing?)" Carlos Blé
51. • Clients should not be forced to depend on methods they don’t use. • "This one was placed here to form the word "solid" but it's the same thing" Carlos Blé Interface Segregation Principle
52. • High-level modules should not depend on low-level modules, but both should depend on shared abstractions • Abstractions should not depend on details – instead, details should depend on abstractions. Dependency Inversion Principle
53. • Basic Idea behind of Inversion of Control (e.g: Spring Framework) • "Never create the instance of the dependency inside the object which uses it." Carlos Blé Dependency Inversion Principle
54. • DRY (Don't Repeat Yourself) • KISS (Keep it Simple, Stupid!) • YAGNI (You ain't gonna need it) Other (Good) Principles
55. Good Principles Online guide: Writing Testable Code http://misko.hevery.com/code-reviewers- guide/ Good Slides: Why our code Smells https://speakerdeck.com/u/bkeepers/p/why-our- code-smells
56. Bibliografy • Growing Object Oriented Software Guided By Tests • xUnit Test Patterns • Refactoring • Clean Code (awesome) • Diseño Ágil con TDD (Spanish)
57. Thanks!
58. Let's get our hands dirty!