The document discusses best practices for test-driven development (TDD), including that unit tests for code should be fast, isolated, repeatable, and run in any order. It recommends writing tests that initially fail for the expected reason, then implementing just enough code to make the test pass and refactoring code. Tests should have a well-defined boundary and avoid technical names or constants. Example code and additional resources on TDD are also referenced.
How to practice TDD without shooting yourself in the foot
1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver
2.
3.
4. • Is fast (i.e. couple of ms)
• Runs in-memory
• Has no I/O-bound dependencies
• Has no static dependencies
• Causes no side-effects
• Should be parallelizable
• Can run in any order
• Has the right scope.
5. • Write a great unit test
• Generate code
• Ensure test fails for the right
reason
• Implement the real deal
• Ensure test succeeds
• Identify alternative scenarios
• Repeat twice
• Refactor.
16. • Define the boundary carefully
• Use BDD or AAA when applicable
• Don’t repeat the context in names
• Don’t use technical names
• Avoid constants
• Use Test Data Builders for the irrelevant
parts
• Show relevant dependencies
• Only assert the relevant parts
• Keep refactoring
• Keep out of the debugger hell.
17.
18. • Example code
https://github.com/dennisdoomen/LiquidProjections/t
ree/TddDemoV2
• Chill
https://github.com/Erwinvandervalk/Chill
• Fluent Assertions
www.fluentassertions.com
• Laws of Jeremy D. Miller
http://codebetter.com/jeremymiller/2005/10/21/haac
ked-on-tdd-and-jeremys-first-rule-of-tdd/
• Xunit Patterns
http://xunitpatterns.com/
• Liquid Projections
https://github.com/dennisdoomen/LiquidProjections
• Test data builders
http://www.natpryce.com/articles/000714.html