I want to run a theory by you regarding unit tests.

They make up for the time they cost to implement in the long run, no doubt, because when you're refactoring you can easily check whether you broke something.

But: what if you've got integration tests covering almost the entire codebase? For those to succeed the unit tests must succeed as well. So therefore imho the unit tests are redundant.

The only advantage of also having unit tests seems that they can pinpoint the issue more accurately.

Any other advantages? What am I missing? Any thoughts/comments?

Large apps, especially those revolving around micro architecture, I'd say worth it.

Medium and small? Mostly not.

With the exception of complex stuff and stuff that's likely to become an obscure headache.

Like if you monkey patch methods or rely on overloads and conditional callbacks.
Those times, a failing unit can give the issue away and save hours of frustration.

Unit tests often are more granular giving a more precise picture of the discrepancy.

Also, most of the time integration tests are more difficult to run on a regular basis.

For example: exporting data to a 3:rd party is often not possible on a per compile test.

But if you have integration tests and can run them automatically on every build they will do much of what unit tests does.

Its just much harder to achieve :)

I've come around to the opinion that unit tests are not actually that useful for testing. And if that's your rationale for using them you'll slowly fall out of the habit.

What they are good for is development. When I'm working on a new piece of code and I know how I want it to work then I'm writing tests as I go to makes sure it's running as expected. No manual end to end tests, no fiddling with the dB getting the test data just so. Just run unit tests.

Integration tests on the other hand are actually valuable after the fact to make sure everything is wired up correctly. Especially if you're using something brain-dead like spring.net for DI

After trying to develop on a codebase for 2 years with no unit tests, I can confidently say they are worth it.
Integration tests are supposed to test the wiring between multiple components, so they cant possibly cover all your codebase unless your project only consists of integrating many other projects that you didnt write. Unit tests should describe the behaviour of an individual component. They dont only tell you if you broke something, they are a very comprehensive form of documentation for the behaviour of the system. As a thought experiment, if you deleted all your production code right now, would the test suite give you enough information to rebuild the system?
Unit tests lose a lot of their value when they are written as a 1-1 mapping to methods in your code. You arent just testing that a method works, you should have unit tests that use multiple classes and methods to test a scenario or use case. Then you will find the unit tests become a lot more valuable. When a test fails you can see exactly which requirement is not being met.

In short I would say unit Tests are Testing units (a component, class, ..) on technical correctness, but in isolation (no db interaction, ..) and Integration Tests are covering business processes (like creating a user)

@CrashOverride I have yet to come across a test suite comprehensive enough to completely describe an entire code base...

Usually the big & complex parts are adequately covered and fool tested.

But the smaller, often glossed over parts like Dto's, wrappers and convenience classes... That's another story.

@lotd Oh believe me I have yet to see this also. This is a very idealistic scenario im describing here, but it is possible to achieve. I havent seen a good test suite yet. Im just saying if you utilise unit tests properly they can be seriously useful and powerful. The worst thing you can have is unit tests that just create objects and assert they are not null. You need to test the behaviour of a component rather than individual methods.

@CrashOverride yes. But then the test is directly married to the object..

So if requirements ever change, it's probably both places

@lotd Im not saying that tests should have a 1-1 mapping to classes either. unit tests should test use cases, scenarios that may make use of multiple objects. The tests arent married to a certain object. They are married to a use case. And if a requirement changes, that use case will change. Its perfectly logical that if a requirement changes, then unit tests will have to change.