Should you write unit tests or integration tests?
I got this question in the mail. I thought it was quite valid for many other people:
Question:
Trying to promote unit tests in a new work place: the “search” action from the UI goes through IOC container which calls a WCF service, where the search itself is done using entity framework auto generated code.
My colleague claims that due to the multiple dependencies, it doesn’t make sense to fake everything when running the unit test, and it makes more sense to do integration tests in this case.
Is my hunch correct? Should I put efforts into implementing unit tests in this complex scenario?
My Answer:
You can go either way.
It really depends on time tradeoffs
- How long will it take to write the tests? For integration tests you will have to wait until the whole system is complete to get the tests even failing, unless you start from a webpage, and then they will fail for as long as the entire system of layers is not built.
- How long does it take to run and get feedback? integration tests take longer to run usually. and are more complicated to setup. But when they pass you get a good sense of confidence that all the parts work nicely with each other. with unit tests you will get faster feedback, but you will still need those integration tests for full system confidence. On the other hand with integration tests and no unit tests the developers will have to wait in long cycles before they know if they broke something.
There is no one answer. I usually do a mix of both. For web systems I might even start with acceptance tests that fail, and then fill the system slowly with unit tests for parts of the features with more focused functionality.
I guess you can change the question to :
What type of tests should we write FIRST?
Only you know that. it changes for every project and system.