Unit-testing – Are integration tests meant to repeat all unit tests

integration-testsrubytestingunit testing

Let's say I have a function (written in Ruby, but should be understandable by everyone):

def am_I_old_enough?(name = 'filip')
   person = Person::API.new(name)
   if person.male?
      return person.age > 21
   else
      return person.age > 18
   end
end

In unit testing I would create four tests to cover all scenarios. Each will use mocked Person::API object with stubbed methods male? and age.

Now it comes to writing integration tests. I assume that Person::API should not be mocked any more. So I would create exactly the same four test cases, but without mocking Person::API object. Is that correct?

If yes, then what's the point of writing unit tests at all, if I could just write integration tests which give me more confidence (as I work on real objects, not stubs or mocks)?

Best Answer

No, integration tests should not just duplicate the coverage of unit tests. They may duplicate some coverage, but that's not the point.

The point of a unit test is to ensure that a specific small bit of functionality works exactly and completely as intended. A unit test for am_i_old_enough would test data with different ages, certainly the ones near the threshold, possibly all occurring human ages. After you've written this test, the integrity of am_i_old_enough should never be in question again.

The point of an integration test is to verify that the entire system, or a combination of a substantial number of components does the right thing when used together. The customer doesn't care about a particular utility function you wrote, they care that their web app is properly secured against access by minors, because otherwise the regulators will have their asses.

Checking the user's age is one small part of that functionality, but the integration test doesn't check whether your utility function uses the correct threshold value. It tests whether the caller makes the right decision based on that threshold, whether the utility function is called at all, whether other conditions for access are satisfied, etc.

The reason we need both types of tests is basically that there is a combinatorial explosion of possible scenarios for the path through a code base that execution may take. If the utility function has about 100 possible inputs, and there are hundreds of utility functions, then checking that the right thing happens in all cases would require many, many millions of test cases. By simply checking all cases in very small scopes and then checking common, relevant or probable combinations f these scopes, while assuming that these small scopes are already correct, as demonstrated by unit testing, we can get a pretty confident assessment that the system is doing what it should, without drowning in alternative scenarios to test.

Related Solutions

Database – Unit/Integration Testing the DAL

Your approach sounds correct. Just be aware that integration tests still need to be repeatable, so you'll have to have a fairly static test database that has all of the tables/views/stored procedures synched to your production codebase. It can be a pain to maintain that, especially with multiple developers. You'll end up with situations where a previous integration tests breaks because someone else went and added a row to a table for one of their integration tests.

One approach I've seen to handle that is, rather than having a "fairly static" database, you have a completely empty database that has all of its objects and data constructed as part of the test setup, and cleared out as part of the teardown. That represents a higher maintenance cost and a non-trivial amount of initial setup work, but may work better if your database schema changes frequently.

Unit-testing – Is using unit tests to tell a story a good idea

Yes, it is a good idea to give your tests names of the example scenarios you are testing. And using your unit testing tool for more than just unit tests maybe ok, too, lots of people do this with success (me too).

But no, it is definitely not a good idea to write your tests in a fashion where the order of execution of the tests matters. For example, NUnit allows the user to select interactively which test he/she wants to be executed, so this will not work the way intended any more.

You can avoid this easily here by separating the main testing part of each test (including the "assert") from the parts which set your system in the correct initial state. Using your example above: write methods for creating an account, logging on and post a comment - without any assert. Then reuse those methods in different tests. You will also have to add some code to the [Setup] method of your test fixtures to make sure the system is in a properly defined initial state (for example, no accounts so far in the database, noone connected so far etc.).

EDIT: Of course, this seems to be against the "story" nature of your tests, but if you give your helper methods meaningful names, you find your stories within each test.

So, it should look like this:

[TestFixture]
public class Authentication_Bill
{
    [Setup]
    public void Init()
    {  // bring the system in a predefined state, with noone logged in so far
    }

    [Test]
    public void Test_if_Bill_can_create_account()
    {
         CreateAccountForBill();
         // assert that the account was created properly 
    }

    [Test]
    public void Test_if_Bill_can_post_comment_after_login()
    { 
         // here is the "story" now
         CreateAccountForBill();
         LoginWithBillsAccount();
         AddCommentForBill();
        //  assert that the right things happened
    }

    private void CreateAccountForBill()
    {
        // ...
    }
    // ...
}

Best Answer

Related Solutions

Database – Unit/Integration Testing the DAL

Unit-testing – Is using unit tests to tell a story a good idea

Related Topic