Handling long-running projects
Published by marco on
This is a brilliant interview, in that Oren Eini just talks for about 40 minutes, answering pretty much just one or two questions.
Oren Eini on Building Projects that Endure by Technology and Friends (YouTube)
At one point (I forget where), he says,
“I don’t like unit tests.”
Agreed. I likelove automated tests. They’re indispensable. But I think unit tests are only useful when you want to focus on a failing integration test. David rightly points out that they’re really good for pinpointing where a problem actually happens, but Eini says that they also “hinder change” because, by their nature, they lock down a lot of the design and implementation.This is absolutely true.
Just to be clear: I think of anything that’s not a unit test as an integration test. I generally like “smaller” integration tests.
It’s probably better to just be agile about it and write them when the situation requires it, i.e., when the cause behind a failing integration test is proving difficult to pin down—or when you’ve determined the cause and you want a direct proof that you’ve fixed the underlying problem.
Ir requires discipline to realize when you need to write more unit tests in order to help pinpoint which component involved in a failing integration test is causing the problem. If you preemptively write all of the unit tests, you’re wasting time that could be better spent elsewhere.
I have had no small amount of success with a large test suite that was mostly integration tests. It ran relatively quickly (10 minutes for 10,000 tests on a reasonably classed developer desktop) and helped me survive three major refactorings.