It’s not so much my clients, but my company, as I’ve never done the contract thing. I wish I could carve out time explicitly, but instead I have to pad my estimates and use the extra time to improve the test coverage, and do my best to encourage a testing culture in the other devs so we don’t fall too far behind.

I’ve been given a lot of freedom to do deep refactorings that both improve the ability to build future features, _and_ provides points that can be mocked to improve testability.

But doing TDD at this point in the development cycle is just painful, unfortunately. I get my TDD fix working on my own projects.

– Morgan

I think the only solution is really just identifying where test coverage is poor (rcov or otherwise), and making sure your client allows you to carve a significant portion of your time systematically improving the test coverage one small piece at a time (in the real world, you’ll almost always have to be continuing to build new features - with tests - at the same time).

I definitely leave autotest way before I’m seeing 5 minute test runs (I’ll focus by hand on a test file or test method such as ‘ruby test/unit/user_test.rb’).

I can’t think of any tools that are going to help you fill the gap any quicker than what you’d use regularly … test/unit, shoulda, heckle, rcov, etc.

Hi, you express here a point I have felt since the early days of “test-first XXXX”.

I do not think that the Agile universe has anything to propose yet to address the ‘large, crufty codebase’, apart from the obvious:

- Struggle to identify functionality suitable for modularization (by leveraging protocol boundaries, file format boundaries), this is probably the most painful step
- Mock modules in the “modern zone” of the code
- Identify a candidate module well surrounded by mocked modules
- Write tests for the surrounded module
- Migrate the candidate module to the “modern zone”
- Iterate

I too have yet to read someone about using BDD in the long run but I am pretty confident that the general direction it shows us is the right one, even if the road ahead is still under construction.

I feel that Gregg has a good point when he says that we have to assimilate that the test part of the code is integral to the code, not just a lateral artifact. Yes there is an increased cost in test infrastructure with BDD, but we must get rid of the depressing sensation that it is a test cost, to embrace the idea that it is THE (normal) cost of developping the code.

Software agility is a virtuous circle.

P.S. I love the title of your post !