29
Big Picture Testing Fluently specifying complex scenarios for integration tests Chris Edwards
Big Picture TestingFluently specifying complex
scenarios for integration tests
Chris Edwards
Roadmap• Integration Testing
– What it is, and common problems• Qualities of a good unit test• Principles for database-facing tests• Practices
– Patterns and Code
INTEGRATION TESTING?What the heck is…
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
Some Assumptions• Tests are automated (CI)• Using a unit test framework• Tests access the database
Common Problems• Brittle• Monster test “SetUp” methods.• “Who changed my data?”• Spend more time fixing tests than writing code
QUALITIES OF A GOOD UNIT TEST
What is a good test?
Qualities of a Good Unit Test
• Clear• Measurable• Meaningful• Atomic• Self-Contained• Robust• Specific
• Repeatable• Isolated• Order-Independent• Fast• Fine-Grained• Autonomous
Integration Tests Differ
Unit Tests• Fine Grained• Fast• Run constantly• Never involves
database• Very little to set up
Integration Tests• Coarse Grained• Slower• Run less often• Often involves
database• Can be a pain in the
#&*!
PRINCIPLES FOR DB FACING TESTS
This ain’t your momma’s unit test.
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
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
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
PRACTICESPractice makes perfect…
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
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
Data Insertion Patterns• Inline Insert• Big Friggin Insert• Anonymous Objects• Object Mother• Fluent Builder
Supported Principle: Data Self-Sufficiency
Pattern: Inline Insert“Insert data required for a test by executing multiple insert statements during test setup.”
Supported Principle: Data Self-Sufficiency
Pattern: Inline Insert
Advantages• Quickest
Disadvantages• Violates DRY• Is Not Clear• Quickly becomes
unmaintainable
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
Pattern: Big Friggin Insert
Advantages• Solves DRY problem of
Inline Insert
Disadvantages• Is Not Clear• Quickly becomes
unmaintainable
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
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
Pattern: Anonymous Factory (Object Mother)
Advantages• Adheres to DRY• Easy to develop• Easy to understand (clear)• Deep graphs are simplified
(auto-created dependencies)
Disadvantages• Can become difficult to
maintain (monster object)• Violates:
– SRP• Creates all objects
– OCP• All methods in one big object
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
Pattern: Fluent Builder
Advantages• 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
Disadvantages• Can be more challenging
to develop up front• Concept of DSL may take
some “getting used to”
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/
Additional Resources• “xUnit Test Patterns: Refactoring Test
Code” – Gerard Meszaros
• “Domain Specific Languages”– Work in Progress by Martin Fowler– http://martinfowler.com/dslwip
About Me
Chris EdwardsSenior Developer, BancVueEmail: [email protected]:
chrisedwards.dreamhosters.comTwitter: @cedwards
BancVue Web: www.bancvue.comPhone: 877.342.2557
We’re hiring C# developersSend resumes to: [email protected]
