Ok, I know I am going out on a limb making a statement like that, so my question is for everyone to convince me I am wrong. Take this scenario:
I have method A, which ca
I agree with you that in your simple case, there is no need for unit tests. Testing (unit, integration, functional, regression) are all dependent on the size of your project and the number of people involved and the level of experience of everyone involved.
As any of these factors increase (well, the last one would have to decrease), then the need for testing increases. You need to find a solution that is appropriate and applicable to your particular project.
I am a big fan of unit tests and believe that all developers should write and automate them regardless of the size of the project. They will ensure that your code is bug free and will really help when you return to the proejct after several months.
I also believe that as you have multiple people working on the project over an extended period of time (read anything other than a throw-away project) then you also need automated integration tests to ensure that the various components work together.
Unit testing is finer grained and allows you to pinpoint errors. What if A or B failed? How would you know which one failed if your integration test failed? And that's only 2 methods -- imagine if you are integration testing a front controller of a web application, which loads a handful of models and calls a bunch of methods. That would be a nightmare trying to track down exactly what went wrong.
If A is a query that runs for 2 hours, and prepares data for B, which is another query that runs for 2 hours, why should I wait 4 hours to find a problem when I could wait 2? It's not like this is a new idea. Do you think car companies assemble the entire car before seeing if the engine works?
Unit tests are not for testing what should be tested in integration - they are complementary sets of tests. Unit tests guarantee that a given unit of code on its own performs what it was designed to do, nothing else. Integration tests make sure all your units work well together to perform what the overall requirements asked.
OK, unit tests won't find every problem, that's why we have integration tests, too!
But suppose you have a method that must return a value between 1 and 9 and you write a test for it and find that it returns a value of null or 10, then you know the code is broken long before you get to integration testing.
I think the major reasons are:
1: unit-level tests give you more information about what's failing.
2: you can't run integration tests until your components are integrated. The sooner you find a bug, the easier/cheaper it is to fix.