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.

1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver

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.

7. Command Handlers
Commands
Domain Model
Event Store
Events
App
Query
Store
RavenDB
Projectors
Events
API Controller
Projections
Events

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.

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