This is a brilliant interview, in that Oren Eini just talks for about 40 minutes, answering pretty much just one or two questions. <media href="https://www.youtube.com/watch?v=BDbhhZoL2jw" src="https://www.youtube.com/v/BDbhhZoL2jw" source="YouTube" width="560px" author="Technology and Friends" caption="Oren Eini on Building Projects that Endure"> At one point (I forget where), he says, <bq>I don't like unit tests.</bq> Agreed. I <del>like</del>love 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 <iq>hinder change</iq> 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.