Integrative Test Driven Development

Integration testing for integrated teams.

Colin FitzGerald
Jul 22, 2014 · 4 min read

Integrative Test Driven Development rethinks the process of writing tests before code. As it stands, many companies deliver a mostly-finished product to QA for testing (if they even have QA to begin with), only for them to discover a catastrophic show-stopper during manual testing or when the Product Manager runs through their acceptance criteria.


Writing a comprehensive suite of tests is time consuming for developers, and while unit tests are excellent at testing isolated pieces of JavaScript or server-side code, they cannot be used to test an app as a single entity. As a result, companies have to make a choice between velocity and quality, which often creates massive backlogs and enormous test debt.

Integrative Test Driven Development works to combine the speed of well-written unit tests with the thoroughness of properly run integration tests, while allowing rapid-feedback about acceptance, and in doing so, preventing a buildup of test-based tech debt. The combination of these processes produces a suite of automated tests that allows a developer to have a firm understanding of their code’s stability, not just at the unit level but as it integrates with a pre-existing product.

By employing a team of QAs to write automated integration tests in tandem with development work, the need for end-stage laborious manual testing is reduced to a bare minimum, and the speed of development and delivery skyrocket. Gone are the days of web developers wrestling with integration tests and use-case scenarios; gone are the days of slow release cycles accompanied by nervous looks and nail biting.

Typically, Product works with Designers to turn a wireframed feature into hi-fi imagery and colors that match business requirements. These are then passed to a developer or group of developers who wire up the pieces and connect them to a database. Here’s where QA usually enters the picture: a near-complete feature is punted to testers to click through and hammer on, in an effort to smoke out any remaining problems as that feature integrates with the existing app. The process of QA is extremely manual and as a result very time consuming and tedious. How many combinations of these input fields are there? By involving a QA team capable of writing Capybara-based integration tests earlier in the process, you invite the opportunity to add fully automated integration tests for the most important scenarios to a developer’s spec.

This means when that final handoff from Dev to QA occurs, what’s being tested is something that has already passed dev-written unit tests, as well as QA-written and PM-approved integration tests. The time usually spent by QA manually clicking through an app is obliterated, and the groundwork for a highly-tested app has been put in place. If you begin developing with this methodology, you create a completely tested app on both a unit- and integration-level, negating test debt and virtually assuring a functional and spec-meeting product, catching bugs before they happen.

A key component of this process is to involve QA early and often. In doing so, element IDs and page wording can be designed in a way that not only meets business requirements, but that makes test-writing smooth and universal. An example? But of course. Capybara employs the method click_button, which can be directed at either an ID or the text of the button. By assuring the text is not repeated on a page, or the ID is named in a way that is consistent across the app, QA can write tests at an intense rate of speed. If all ‘Cancel’ buttons have the same ID across an app, and every confirmation message contains a single page-unique word of (eg “Successful”), test writing becomes a breeze for your QAs, and one less burden for your developers. As your app develops and grows, these IDs remain constant, and can be repeatedly referenced by your QAs as they write tests for future features.

Your integration tests become QA’s responsibility: they own them, which involves both writing and maintenance. This frees up developers to do what they do best, instead of spending time repairing brittle integration tests.

Because of the time saved by this standardization, automated integration tests can be delivered to Developers well in advance of their feature’s completion. From that point on, running their specs will give them much of the same information that hours of manual testing would in a fraction of the time.

QAs can manually ensure functionality at previously unheard of speed, and Product can rest assured that what they wireframed and designed is what’s being produced.

Integration testing for integrated teams.

    Colin FitzGerald

    Written by

    photo fan; enthusiasm enthusiast; director of quality at green bits. opinions are my own.