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: ChrisEdwards357@gmail.comBlog:

chrisedwards.dreamhosters.comTwitter: @cedwards

BancVue Web: www.bancvue.comPhone: 877.342.2557

We’re hiring C# developersSend resumes to: michael.scallan@bancvue.com