I have a dev, that will get around our code coverage by writing tests that never fail.
The code is just atrocious, but the tests never catch it because they assert(true).
I code review, but I can't do everyones work for them, all the time. How do you get people like this motivated to make good software?
Is there a build plugin for detecting tests that can't fail?
C#, mbUnit tests.
You should really specify the language / framework you're using.
In the simplest case, I suppose it should be easy to detect assert(true) strings with simple grep-ping.
You could always try a test run with garbage for the application configuration values.
Any tests that pass are suspect?
Real motiviation comes from within. Some people will game the system every chance they get sometimes for no other reason than they can. Others do it simply because they are hacks.
That said, assuming your the manager, have a "come to jesus" meeting with the dev. If that still doesn't work, there's always the door.
If you're not the manager, then take it up the proper channels.
I think you've almost answered the question for yourself there. If you have someone work for you or with you (you're not clear no whether you are this dev's manager) then if they are not doing the job properly then surely there are procedures that are available to make it clear to this person that they are not producing work to an acceptable standard.
Is the dev new to TDD? Maybe they need some tuition on writing good tests etc. Otherwise they need a kick up the ass and have it stressed to them that the tests are as if not more important than the code he/she is producing.
Oh yeah, and on the plugin thing, forget that, just the same code reviewing you're doing should be good enough.
Instead of spending time on looking for tests that can't fail, how about extending the tests a bit - make the code fail in many ways. That would
A piece of buggy code you have to use would be a good starting point -- you must be sure it works...
Take the interface he's testing and reduce it to it's simplest form. In other words, take the class/method signatures and only add the code needed to compile beyond that. Run his tests against that. Ask him why his tests are passing when the program does nothing.
Code Review, by two or more developers who are already test infected, is probably the best way to get the dev in question to see that automated unit testing is really not that difficult, nor unusual. Having two test infected developers on each review will reinforce the importance of quality unit tests to him. Also, assigning him reviews of other developer's code which is well tested will help him learn how to unit test.
You should have a look at doing some mutation testing, to detect weak tests. Nester, (the .Net equivalent of Jester) is one tool which you may find useful.
Please let us know how you go!
Update: I came across: "Why do most developers not write unit tests, still?" and thought it would be good reading here as well.