Big Picture Testing

1. Big Picture Testing Fluently specifying complex scenarios for integration tests Chris Edwards

2. Roadmap • Integration Testing • What it is, and common problems • Qualities of a good unit test • Principles for database-facing tests • Practices • Patterns and Code

3. What the heck is… Integration testing?

4. What is Integration Testing? “Integration testing … is the activity of software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before system testing.” -Wikipedia “If it hits the database, it’s not a unit test” -Some Smart Guy

5. Some Assumptions • Tests are automated (CI) • Using a unit test framework • Tests access the database

6. Common Problems • Brittle • Monster test “SetUp” methods. • “Who changed my data?” • Spend more time fixing tests than writing code

7. What is a good test? Qualities of a good unit test

8. Qualities of a Good Unit Test • Clear • Measurable • Meaningful • Atomic • Self-Contained • Robust • Specific • Repeatable • Isolated • Order-Independent • Fast • Fine-Grained • Autonomous

9. Integration Tests Differ Unit Tests Integration Tests Coarse Grained Slower Run less often Often involves database Can be a pain in the #&*! • Fine Grained • Fast • Run constantly • Never involves database • Very little to set up

10. This ain’t your momma’s unit test. Principles for db facing tests

11. Principle of Data Self-Sufficiency “A test should insert any data it needs into the database.” Stated another way: “A test should not depend upon any pre-existing data in the database.” • Supported Qualities • Atomic • Robust • Clear

12. Principle of Intrinsic Data Assurance “For data that is intrinsic to the system (required for operation), tests should be written to assert its existence.” • Supported Qualities • Robust • Clear • Specific

13. Principle of Side-Effect Free Execution “A test should rollback any changes it makes to the database regardless of whether the test passes or fails.” • Supported Qualities • Repeatable • Robust

14. Practice makes perfect… Practices

15. Pattern: Auto-Rollback Test Base Class “Ensure Side-Effect Free Execution of tests by deriving them from a base class that starts a transaction on setup and rolls it back on teardown.” Supported Principle: Side Effect Free Execution

16. Pattern: Intrinsic Data Test “Ensure data intrinsic to the execution of the system is not missing or invalid by asserting its existence in a test.” Supported Principle: Intrinsic Data Assurance

17. Data Insertion Patterns • Inline Insert • Big Friggin Insert • Anonymous Objects • Object Mother • Fluent Builder Supported Principle: Data Self-Sufficiency

18. Pattern: Inline Insert “Insert data required for a test by executing multiple insert statements during test setup.” Supported Principle: Data Self-Sufficiency

19. Pattern: Inline Insert Advantages Disadvantages Violates DRY Is Not Clear Quickly becomes unmaintainable • Quickest

20. Pattern: Big Friggin Insert “Insert data required for multiple tests by using a common data set created by executing multiple insert statements that is shared across tests.” Supported Principle: Data Self-Sufficiency

21. Pattern: Big Friggin Insert Advantages Disadvantages Is Not Clear Quickly becomes unmaintainable • Solves DRY problem of Inline Insert

22. Pattern: Anonymous Object “Remove unnecessary detail from a test by randomly generating unimportant data.” Or “Clarify your tests by only specifying the things you need.” Supported Values: • Clear • Specific

23. Pattern: Anonymous Factory (Object Mother) “Simplify creation of graphs of complex objects by creating a central object to manage their creation.” Supported Values: • Clear • Specific

24. Pattern: Anonymous Factory (Object Mother) Advantages Disadvantages Can become difficult to maintain (monster object) Violates: SRP Creates all objects OCP All methods in one big object • Adheres to DRY • Easy to develop • Easy to understand (clear) • Deep graphs are simplified (auto-created dependencies)

25. Pattern: Fluent Builder “Simplify and clarify creation of complex graphs of objects by creating a fluent interface (DSL) to describe and build them.” Supported Values: • Clear • Specific

26. Pattern: Fluent Builder Advantages Disadvantages Can be more challenging to develop up front Concept of DSL may take some “getting used to” • Extremely easy to use • Discoverable interface • Nesting simplifies complex graphs • Much easier to understand (even for complex graphs) • Adheres to: • SRP • One builder per class • OCP • Adding new builders is easy

27. Fluency.NET “A framework for creating a .NET fluent interface for building anonymous object graphs for testing.” Source: http://github.com/ChrisEdwards/FluentObjectBuilder/ Blog: http://ChrisEdwards.dreamhosters.com/

28. Additional Resources • “xUnit Test Patterns: Refactoring Test Code” • Gerard Meszaros • “Domain Specific Languages” • Work in Progress by Martin Fowler • http://martinfowler.com/dslwip

29. About Me Chris Edwards Senior Developer, BancVue Email: ChrisEdwards357@gmail.com Blog: chrisedwards.dreamhosters.com Twitter: @cedwards BancVue Web: www.bancvue.com Phone: 877.342.2557 We’re hiring C# developers Send resumes to: michael.scallan@bancvue.com