Fine line between integration testing and unit testing

badaiaqrandista has asked for the wisdom of the Perl Monks concerning the following question:

Hi all,

I have small conceptual problem learning the path of TDD. I have an application that is nicely modularised. Two of the logical groups of the modules in it are business entity modules and data access modules. The business entity modules implement the business concepts and accesses the database through the data access modules. The data access modules are homegrown modules that behave like DBIx::Simple.

I am trying to test one of the business entity modules. I am using Test::MockObject to mock the call to the data access modules. While doing that, I find myself tempted to use DBD::Mock to mock the sql results that the data access modules will accept and then return it in the appropriate data structure, instead of just mocking the return value. However, I feel like it is an integration testing and not unit testing.

Is it a good practice to test multiple modules at once in unit testing? What is the line that differentiate between unit testing and integration testing?

Thanks

--------------
badaiaqrandista

Comment on Fine line between integration testing and unit testing

Replies are listed 'Best First'.
Re: Fine line between integration testing and unit testing by kvale (Monsignor) on May 10, 2006 at 03:34 UTC
In the decision between unit testing and integration testing, both is better :) Unit testing usually refers to testing single functions or methods, while integration testing tests the compatibility among functions, methods, classes, components, etc. In practice, the distinction between unit and integration testing is blurry. For instance, a method may invoke private helper functions not accessible in the public API. So the distinction in between unit and integration testing is not as important as testing at all levels. Start with the smallest logical units of testing, such as functions or even assertions within functions. Then work your way up the chain as you write more code. In the context of your problem, it would make sense to mock the return value at first to test the business entities alone. Then test the data access modules with DBD::Mock, and then perform integration testing between the business entity and data access modules. -Mark	[reply]
Re^2: Fine line between integration testing and unit testing by badaiaqrandista (Pilgrim) on May 10, 2006 at 06:52 UTC
Thanks for your reply. I guess, designing tests needs the same dicipline as designing the application itself. -------------- badaiaqrandista	[reply]
Re: Fine line between integration testing and unit testing by adrianh (Chancellor) on May 10, 2006 at 09:06 UTC
am trying to test one of the business entity modules. I am using Test::MockObject to mock the call to the data access modules. While doing that, I find myself tempted to use DBD::Mock to mock the sql results that the data access modules will accept and then return it in the appropriate data structure, instead of just mocking the return value. Why? (he asks curiously :-) I would have thought mocking the database would be harder than mocking the data access module? Is it a good practice to test multiple modules at once in unit testing? What is the line that differentiate between unit testing and integration testing? In this particular instance you won't be doing unit testing any more since you are relying on two of the modules you are developing working to get a correct result. If you're using your data access module to test your business entity module a bug in your data access module could cause your business entity module test to erroneously pass or fail. However, if you have good tests for your data access module then the bug should be caught there. So it may not be an issue. This is completely orthogonal to the issue of TDD. You can write integration tests first just like you can write unit tests first - and both are useful in different situations.	[reply]
Re^2: Fine line between integration testing and unit testing by badaiaqrandista (Pilgrim) on May 10, 2006 at 23:33 UTC
Why? (he asks curiously :-) Because it seems like killing two birds with one stone (which probably means: I want the benefit of automated testing without testing every single code path) Thanks for the reply. -------------- badaiaqrandista	[reply]
Re^3: Fine line between integration testing and unit testing by adrianh (Chancellor) on May 11, 2006 at 08:46 UTC
Because it seems like killing two birds with one stone (which probably means: I want the benefit of automated testing without testing every single code path) The problem you'll get is that it suddenly gets a whole lot more complicated to diagnose problems if something breaks in that middle layer that's not being explicitly tested. You also end up running more and longer tests since you can't test components in isolation.	[reply]