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.

  • Comment on Re: Fine line between integration testing and unit testing

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

    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
      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.