in reply to Fine line between integration testing and unit testing
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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Fine line between integration testing and unit testing
by badaiaqrandista (Pilgrim) on May 10, 2006 at 23:33 UTC | |
by adrianh (Chancellor) on May 11, 2006 at 08:46 UTC |