> In my experience test makes it harder to add code, since usually way too many tests test implementation details. This is actually one of the reasons why I ad

> In my experience test makes it harder to add code, since usually way too many tests test implementation details. This is actually one of the reasons why I adopt a test-first methodology. It's very hard to couple your test to implementation details if no such details exist yet. Combined with writing automated tests on a use case level rather than a lower level, I end up with pretty robust test suites. So instead of addToBasket(basketId=1234, productId=9) basket = fakeDb.getBasket(1234) assert 9 in basket fakeDb.insertBasket(<<basket with product id 9>>) basketView = viewBasket(1234) assert 9 in basketView I'm more likely to have a single test mimicking actual user behavior, like addToBasket(basketId=1234, productId=9) basketView = viewBasket(1234) assert 9 in basketView This tends to be more robust because use-cases for existing functionality tend not to change too much. And when they do, it makes sense for your test suite to change accordingly. Writing tests on an even lower scope makes the suite even more brittle. If the addToBasket endpoint is composed of three subroutines, and you write tests for each subroutine individually, then as soon as you refactor to some other number of subroutines, your test suite breaks even though the endpoint still works. One reason why writing your tests first is effective in producing tests decoupled from implementation details is that if you write the test first, it's much more natural to write a higher scope test. > The problems he write technical solutions to are social not technical. Pretty much all of the software we use today are technical solutions to social problems. Why is this problematic to you?