> It takes me twice a long to get my integration tests to work if I don't have unit tests making sure the parts work along the way.

That's a valid concern, but if your unit-tests are only for making sure that part you just wrote works as expected than just have a test-case up for that specific part, and change it when you move to the next part.

The value of unit-tests is supposed to be regression testing: when you change something that breaks a different unit in a different part of the stack.

> If you write an integration test, and it fails, what's broken?

Well, I debug it it the same way I debug any bug. After all, most bug reports are from a full execution in the field; I am probably already set up to debug the full application anyway[1].

[1] Once a bug reproduction is set up in a fairly automated way.

you know... you debug and find out

The thing about unit tests is that the better they are, the less you have to debug.

A very good one, with effective use of matchers, you don't even have to read the test to know what you did wrong. You just know from the error message what you broke.

> The thing about unit tests is that the better they are, the less you have to debug.

>

> A very good one, with effective use of matchers, you don't even have to read the test to know what you did wrong. You just know from the error message what you broke.

Agree, and agreed. The counterpoint is that unit-tests take time to write and time to maintain - you have to balance that time spent against the time that you would spend debugging an integration test.

Integration tests take far more time to maintain. Major functionality changes can affect all of your tests. With unit tests they may invalidate a few, but that’s okay because they were cheap to begin with.

If your unit tests are hard, you need to refactor your code.

> Integration tests take far more time to maintain.

So? You're going to have them anyway or else you can't deploy.

> Major functionality changes can affect all of your tests. With unit tests they may invalidate a few, but that’s okay because they were cheap to begin with.

Orders of magnitude matter, and if you have a testing pyramid instead of a testing ice cream cone, there can be up to two orders of magnitude difference between the number of unit tests and integration tests.

If you start with unit tests, then the integration tests are just verifying the plumbing. That only changes when the architecture changes, which is hopefully a lot less than how often the requirements change substantially.