Powered by Blogger.

Unit vs Integration Testing


I have started to get my feet wet on TDD (Test Driven Development) and the first thing that I come across in any article/posts/online courses is about Unit and Integration testing. Now, I do have some understanding of what is unit and integration testing and how are they different. I had got this understanding through talking to my colleagues or just glancing through some study material but never had a formal knowledge of these and especially how they differentiate.

Below I am trying to define both these types of testing and try to highlight the difference between these two.

Unit Testing: Unit Testing is all about testing a single unit of code most commonly, a single method in a completely autonomous way. Autonomous here is that the method has a life of its own and has no dependencies on other parts of the program. While unit testing we assume that the rest of the application/class is behaving as expected. This is a very important difference I see between the unit and integration testing. Hence, if a unit test for a method succeeds, it does not say anything about the whole application neither about the class in which the said method is implemented.  It just tells us that if we give some particular data to this method, it will return the desired output provided the dependencies are working correctly.  In unit testing, we may employ Mocks to make sure we don’t depend on external factors.

Integration Testing: Here we combine 2 or more pieces of logic to prove that they are working as expected.  Testing of a single method can also be termed as Integration testing if the said method has dependencies on other classes/methods and we end up using those dependencies for testing. Integration testing can also, involve other servers/databases, like calling separate APIs. It's important to understand that if we write a test case calling a single method, but if that method gets its data from other parts of the application then that would mean it’s an integration test. One point to consider about integration testing is that if an integration test fails it does not directly tell us where the error is.

e.g.

public string returnStartsWith(string str)
{
    if(!string.isNullorEmpty(str)
    {
        return str.substring(0,1);
    } 
    else
    {
        return null;
    }
}

The above method is a single entity and does not depend on any outside factor hence, writing a test case for this specific method will be a unit test.

public string returnStartsWith()
{
    //get str from external source, can be a DB, File source, or any other method which may provide str
    if(!string.isNullorEmpty(str)
    {
        return str.substring(0,1);
    } 
    else
    {
        return null;
    }
}

In this method, we are getting “str” string from outside of this method and to test this method as-is we would be writing an integration test because if the test fails we would not have a clear idea whether the test failed because of this method or the external source from which we are getting the “str”. But, if we would mock the external source and get the data then that test case would be a unit test because now the possible failure would point us to this method only.

In end, I think we should distinguish between unit and integration test because that would help us determine the possible place of error if either of them fails. If it’s a unit test I would know exactly where to look for the problem, if it’s an integration test then I would have to look at different places (layers/methods) to identify the root cause, which is not necessarily a bad thing. It's just that we should be aware of which type of test cases we are executing and that will help us determine where to go.

A good source to understand unit vs integration testing: http://stackoverflow.com/questions/10752/what-is-the-difference-between-integration-and-unit-tests

No comments