[Fr3dd1]

I had quiet a ride myself with that topic. For years my opinion was, that I dont want to, as the auther here suggests as well, go with tdd as long as I dont know exactly what I need. Than I switched over and used tdd for everything with a more regid (interface) design upfront. Nowadays I use tdd from the integration side and only add unit tests later or case by case when I think its usefull. A really good ressource is "Growing Object-Oriented Software, Guided by Tests"

[perrygeo]

> tdd from the integration side and only add unit tests later

This is where I've landed as well. Unit tests are for locking down the interface, preventing regressions, and solidifying the contract - none of which are appropriate for early stages of feature development. Integration tests are almost always closer to the actual business requirements and can prove direct value - ie only once the integration works, then lock it down with unit tests.

I've also toyed with a more radical idea: don't check your tests into the git repo. Or at least keep the developer tests separate from the automated tests. Think about it: what rule says that the tests used in development should go directly into the CI test suite? One is designed to help you navigate the creative process, the other is designed to prevent regressions. I think we do a disservice by conflating the two scenarios into one "testing" umbrella. During TDD, I need far more flexibility to redefine the shape of the tests (maybe it requires manual setup or expert judgement or ...) and I don't want to be hampered by a (necessarily) rigid CI system. Dev tests vs CI serve two completely different purposes.

[Fr3dd1]

Interesting idea but what exactly is a dev test for you? And when does it qualify as a ci test?