I totally agree. Having been in the same shoes this is the best route usually. I am all for setting up CI and have the ability for a failed test to fail the bu

I totally agree. Having been in the same shoes this is the best route usually. I am all for setting up CI and have the ability for a failed test to fail the build etc, but start simple. Pick a framework you can all agree seems reasonable and write tests for things that break. Then as you add new code write tests there too. As you do this you will quickly wind up with 10 then 30 etc and the tests will just start building up and before you know it you have a serious test suite and your mindset will have shifted. Personally I do not start a new project with TDD. I know I will likely get smacked for admitting it. But to me get the basic app whipped into a useable product then introduce more discipline via testing this way. That way yes you pay some for it, but you have clients or a slid demo etc. Writing a great app with tons of tests that misses the mark doesn't benefit anyone. Faster iteration early on is more important. Of course I caveat this some, if you are adding a component to an already built system or in an enterprise I'd likely build tests first.