Well I guess the real problem would lie on defining what "sufficient" code coverage is. There was this post on object mentor (blog.objectmentor.com/.../100-code-coverage)that said that "if your goal is 100% coverage, you’ll focus on that goal and not focus on writing the best tests for the behavior of your code."

So the challenge would be to strike a balance between teaching the *value* of TDD and code coverage, as well as writing good tests, so that the objective is not 100% code coverage, but instead, something like 80% code coverage but *with very good tests*

At the risk of sounding draconian, you could insist that no code be committed to the code base unless accompanied by the appropriate test cases.  To make this more manageable, you could enforce this policy on the newer developers only.

If the new developers still do not understand the value of TDD, then the only thing you can do is seduce them to the test driven way of programming :D. Most of the times, though, they are the ones that produce the most bugs. When defects arise, take advantage of the situation and let the team think of the tests that would have uncovered that bug if only the code was test driven. It is not directly helping to the "code coverage" metric but it doesn't matter. What matters is that the team learned something out of the bug. Hopefully, the guy that introduced the bug learned something, too.

There are also those developers that are test driven already but are tempted to go back their old ways because they think they've hit a hard to test code. When that happens, then you can just all agree to call up a meeting and brainstorm on the ways to test it. I think when you start doing this, you'll get meetings every few minutes. But as you go along and gain a lot of experience writing tests, the meetings should eventually dwindle. This idea came from Michael Feathers (I think) but I am unable to find a link.

Not sure if I'm qualified. I myself am not putting up as much tests as I should, nor am I putting up tests firsts the way I should. :p

These things are what you miss cruizer for.

I have a new post in my blog (dotnet.kapenilattex.com) that somewhat answers some aspects of your quandaries. Hope it helps :)

Yipes, I should've read your post more carefully before talking out of the proverbial you-know-what.  Yes, including coverage in the build success criteria is better than a policy (we live in PHP land where unit testing/coverage tools aren't quite up to snuff).

Do you personally insist on 100% coverage with the code you write?  If so, (and I have a feeling you do =), then  apply that standard and expect the same from your group, they will be better off for it.

OT: Yup, 8th floor.  Pay us a visit anytime. =)

# jokiz

I understand your situation. Someone leaves and their knowledge about the module is not encoded in test form. The leaver will be asked to create a handover "braindump" document detailing whatever it is that is needed to be explained to the pitiful guy that will takeover the application.

I think there is a better way. Rather than ask the leaver to create the document, I think it is much better to just take over the application on the very day that he filed his resignation and try to work on the application. Start adding tests and refactoring, while the person is still there and you can still ask questions. Look for the biggest files, biggest, classes, longest methods, most complicated code, and work from there. Read Micheal Feathers' book and then memorize Resharper's short-cut keys. You'll be using it a lot. :D

Lexapro side effects. Lexapro and weight gain. Lexapro. Lexapro and side effects.

Avandia.

Effexor xr. Effexor xr emotional dullness. Effexor xr 37.5mg.