Tests that talk
- 1. TESTS THAT TALK or 10 simple rules for cleaner, maintainable, readable tests
- 2. USEFUL RESOURCES • Effective Unit Testing: A guide for Java developers - Lasse Koskela • Clean Code & Clean Coder - Uncle Bob • Test Driven Development - Kent Beck • Specification By Example - Gojko Adzic • Agile Testing: A Practical Guide for Testers and Agile Teams - Lisa Crispin & Janet Gregory
- 3. DISTRIBUTE YOUR EFFORTS #1
- 4. Unit tests Component tests Integration tests Performance tests Acceptance Tests
- 5. #2 TEST CODE IS AS IMPORTANT AS PRODUCTION CODE
- 6. • It should be clean & maintainable • it should be efficient and effective • its behaviour should be deterministic • don’t live with dead code • this includes ignored tests!
- 7. • Given-When-Then / Given-Expect #win • Name test methods like “shouldXXX” • Use alphabetic suffixes rather than numerical as its easier to read
- 8. TEST ONE THING AT A TIME #3
- 9. •Makes tracing failures easier •Avoid loops, use parameterisation • Promotes re-use of code • Coupled with BDD-esque style means test reports form detailed behavioural specifications
- 10. ENCAPSULATE DATA OBJECT CREATION #4
- 11. • Exploit builder patterns and internal DSLs for more human-readable test setup • Don’t mix test code with testing utility classes •Test your utility classes (reuse!)
- 12. MOCKING #5 INTRODUCES FRAGILITY
- 13. • An expectation on a mock object is an implicit assumption that the concrete implementation behaves in a specific way • Has a tendency to introduce tight coupling •Try to mock only across boundaries: view-controller <-> service layer <-> persistence layer • Minimise the amount of verification on mock objects
- 14. DON’T REBUILD THE WORLD IF ALL YOU NEED IS TO REBUILD THE HOUSE #6
- 15. • Setting up test environments can be expensive • When loading data, e.g. DbUnit, try and minimise the dataset size •Typically the higher up the “test pyramid” the more expensive • If a test “dirties” the environment prefer cleaning up over recreating the environment • Isolate tests to allow parallel execution on a shared environment, e.g. user objects in integration tests
- 16. ASSERT IN ENGLISH* *(IRONY NOTED) #7
- 17. • JUnit’s assertThat + Hamcrest is a good start •Writing custom matchers is easy •Generics are a PITA •Awaitility is a DSL for working with asynchronous APIs • JodaTime API is great for date/time comparisons • Assertj is an extensible assertion framework more natural than JUnit’s
- 18. CATEGORISE YOUR TESTS #8
- 19. •Group by: •Speed • Feature set •Work in progress •Layer •OS/Browser •Provide methods to execute a collection of test groups as well as the full suite
- 20. #9 GO NATIVE
- 21. •Encourage non- & semi-technical participation in feature specification with BDD frameworks • JBehave •CucumberJVM •RAML •lambda-behave • Be the agent of change: Spock
- 22. HAVE FUN! #10
- 23. IMAGES SOURCES • http://free-extras.com/images/broken_heart-1503.htm • http://www.makergear.com/products/m-series-3d-printers • http://xkcd.com/435/ • http://justfree.org/fruit-clip-art
- 24. TESTS THAT TALK or 10 simple rules for cleaner, maintainable, readable tests