CODEWITHSUNDEEP
testingtddintegration-testing
Kevin Behan
Kevin Behan

Reputation: 496

How to decide when and when not to create an integration test

Is there a definitive process for deciding what in your codebase you should create integration test suites for? I'm talking... "This part of my code meets A criteria, thus tests should be created. This part of my code meets B criteria, thus tests should not be created."

As my Rails application grows significantly in size I'm adding small features (in comparison to the overarching structure) like a field on a User account that dictates whether or not the User is allowed to create an appointment for his or herself or he or she requires a parent to do so (I understand that the implications of this going wrong COULD be significant, but I'm merely trying to elucidate the minuteness of this feature's implementation).

Should integration tests be field specific -- as in the case stated above? Or should they be more comprehensive and integrated? A pellucid process for "yes" or "no" to integration test creation is what I'm looking for. Does it exist?

Upvotes: 4

Views: 822

Answers (2)

stevo999999
stevo999999

Reputation: 608

If you could get small tweaks working without errors then you don't need an integration test. However, once you start running into 2 or 3 bugs, or if you foresee yourself running into problems because of the complexity (use your intuition and experience) then you need tests.
An actual formula thats more specific than this is impossible because tests are designed to detect bugs which are not supposed to be there. Therefore, without detecting the bug (writing the test) its impossible to know if it exists.

Upvotes: 2

Dave Schweisguth
Dave Schweisguth

Reputation: 37617

There is no way to decide whether or not to write an integration test that you can use without thinking. Any real application has nuances and special cases that challenge any rule. But there is certainly a common approach which you can follow except in cases where you find it doesn't fit: the approach of using acceptance tests as integration tests.

Side note: I'm taking "integration test" to mean a test which exercises more than one layer of your code, not the Rails-specific meaning which has mostly been subsumed by better methods and tools. But my answer applies if you do use Rails integration tests.

An acceptance test captures an important user flow. It is also an integration test, exercising all layers of the application from UI all the way through the back end. Behavior-Driven Development (BDD) and similar methodologies drive development outside-in by writing acceptance tests for all important user flows. Acceptance tests are complex to write and slow to run, so one tries to write the smallest number of them possible which still defines all important user flows.

Choosing acceptance tests is an art, but a rule of thumb is that if two scenarios involve different actors and/or different major system components (e.g. UI screens) they should have separate acceptance tests, and if not they're the same scenario with details and one acceptance test is sufficient.

Acceptance tests are useful in communicating with your stakeholders (i.e. recording requirements), so you want them regardless of the rest of your testing strategy. But it's common to find that a full set of acceptance tests is all the integration tests that you need. Detailed requirements that don't merit acceptance tests can be expressed in unit tests.

In your example, I would probably write one acceptance test for a scenario where a user creates their own appointment and another for a scenario where a parent has to help, because they'd be quite different. The first would be something like (using Gherkin)

When I visit the new appointment page
And I create a new public appointment
And I visit my calendar
Then I see the public appointment

but the second would be quite different:

When there is an unrestricted user "Dad"
And there is a restricted user "Billy" supervised by "Dad"
And there is a user "Stalker"
When "Billy" visits the new appointment page
And "Billy" creates a new appointment
And "Billy" visits his calendar
Then "Billy" sees a pending appointment

When "Stalker" visits "Billy"'s calendar
Then "Stalker" does not see an appointment

When "Dad" visits "Billy"'s calendar
And "Dad" approves the pending appointment
Then "Dad" sees an appointment

When "Billy" visits his calendar
Then "Billy" sees an appointment

When "Stalker" visits "Billy"'s calendar
Then "Stalker" does not see an appointment

On the other hand, I would probably not write two different acceptance tests for scenarios with and without a location (assuming that location is just a text field that might or might not be filled in). Unit tests would probably suffice there.

Upvotes: 2

Related Questions