Integration Tests

Two teams work on two different components of a project. Team A works on component A, and to keep things simple, Team B works on component B. The system needs both components to function.

There’s an additional catch. Team A needs component B to test A. Team B needs component A to test B.

So what to do? Well they would do what any good team would. Team A goes on holiday while Team B finishes and then Team B relaxes. Unfortunately that isn’t always possible. 

Instead, they would use mocks, whether they create their own stubs/fakes or use an existing framework. To verify that component A works, Team A uses mocks to replace component B’s functionality. Team B uses mocks to replace component A’s functionality. All tests pass.

The next step would be to integrate the two subsystem and put it in production. I mean surely if all subsystem tests pass, it should work……the reality is it probably won’t.

 

The moral of the story: Two halves don’t necessarily make a whole. Don’t skip your integration tests. It’s not a waste of time. And integration tests aren’t just about running all your unit tests on a continuous integration server. They are integration tests, not isolated unit tests.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s