Unit testing-patterns


Published on

This talk answers questions asked about unit testing by attendees at ALE 2013.

It was created in two hours, starting from an open space session where we gathered the questions.

Published in: Technology, Education

Unit testing-patterns

  1. 1. Unit Testing Patterns or How a talk looks like when you take it over one day before giving it
  2. 2. We are the Code Retreat Brothers @alexboly @adibolb First European Code Retreat, co-facilitated with Maria Many Code Retreats around Europe
  3. 3. Disclaimers 1.Nobody was hurt while creating the talk 2.It's the fastest talk we ever created 3.It answers your questions 4.We might be wrong 5.It might contain jokes and 5-level pyramids
  4. 4. The top 5 things I'd like to do in the next hour Talk, talk, talk Discuss, answer questions Practice Rescue legacy code or tests Learn He told me I could draw
  5. 5. So, unit testing patterns. What do you want to learn?
  6. 6. Here's what we'll answer 1. What to unit test? 2. How to organize tests? 3. How to deal with complex test setups? 4. How to avoid brittle tests? 5. How to integrate devs & testers in the team? 6. How and when to introduce tests on legacy code? 7. How to do Javascript unit testing? 8. How to unit test databases?
  7. 7. But before that, some background ● Pyramid of tests ● Behavior Slicing ● Unit Test Structure ● Stubs vs. Mocks
  8. 8. Pyramid of Tests
  9. 9. How you should do testing Unit Tests Integration tests Component tests System tests ... That's the 5 level pyramid estimation error
  10. 10. How you really do testing Unit Tests Integration tests Component tests System tests ... UnitTests Integrationtests Componenttests System tests ...
  11. 11. Behavior Slicing
  12. 12. How many tests should you write for this code? public int sameNumber(int number){ return number; }
  13. 13. How many tests should you write for this code? public int sum(int first, int second){ return first + second; }
  14. 14. How many tests should you write for this code? public DateTime daysAfter(DateTime date, int days){ ... }
  15. 15. Behavior Slicing ● The process to identify behaviors that the code should do ● How: – Identify input and output – Choose the important values for input (value sampling or equivalence partitioning) ● Write one unit test per behavior
  16. 16. Property based testing @forall(x=[1,2], y=[20,30]) def test_can_specify_fixed_sequence_of_inputs(x, y): assert x in (1,2) and y in (20,30)
  17. 17. Stubs vs. Mocks (Alex needs to say two jokes)
  18. 18. Stubs vs. Mocks Both are test doubles, but: ● Stubs return values ● Mocks check method calls
  19. 19. What to test?
  20. 20. Risk-based testing ● What is the feature that, if it doesn't work, you loose money? ● What is the part of the code that, if it doesn't work, will bring the system down? ● What is the most complex part of the software? ● What are the types of mistakes the team makes when developing?
  21. 21. How to organize tests? ● Will not show the 5-level pyramid again
  22. 22. How to deal with complex test setups? ● One behavior per test ● Object Mother – creates examples for tests – e.g., the 'John' employee ● Builder pattern: – aDate.withDay(1).withYear(2013).build(); ● Maybe your production code design needs improvement
  23. 23. How to avoid brittle tests? ● One behavior per test (focus on behavior) ● Adjust level of checks ● Short tests
  24. 24. How to integrate devs and testers? ● Cross functional teams ● Pair tester and programmer on stories ● Maybe: Developer in Test role – Watch Aimee Rivers' talk on http://2013.itakeunconf.com
  25. 25. How and when to introduce tests on legacy code? ● On modules with high cost of failure ● Whenever changing the code – fixing a bug – adding a feature – code improvements ● If the code doesn't need to change, don't test it ● Start from integration tests and go down the pyramid
  26. 26. Javascript unit testing ● Watch James Shore testing Javascript at http://vimeo.com/68334907
  27. 27. Testing Databases ● Stored procedures, functions => DbUnit ● Access, check ORM works, queries are correct => Integration tests ● Performance, scalability etc. => tools
  28. 28. Any other questions? “The important thing is to never stop questioning”
  29. 29. Thank You! @alexboly @adibolb