How to make junior programmers write tests? [closed]

We have a junior programmer that simply doesn't write enough tests.
I have to nag him every two hours, "have you written tests?"
We've tried:

• Showing that the design becomes simpler
• Showing it prevents defects
• Making it an ego thing saying only bad programmers don't
• This weekend 2 team members had to come to work because his code had a NULL reference and he didn't test it

My work requires top quality stable code, and usually everyone 'gets it' and there's no need to push tests through. We know we can make him write tests, but we all know the useful tests are those written when you're into it.

Do you know of more motivations?

Solution 1:

This is one of the hardest things to do. Getting your people to get it.

Sometimes one of the best ways to help junior level programmers 'get it' and learn the right techniques from the seniors is to do a bit of pair programming.

Try this: on an upcoming project, pair the junior guy up with yourself or another senior programmer. They should work together, taking turns "driving" (being the one typing at they keyboard) and "coaching" (looking over the shoulder of the driver and pointing out suggestions, mistakes, etc as they go). It may seem like a waste of resources, but you will find:

1. That these guys together can produce code plenty fast and of higher quality.
2. If your junior guy learns enough to "get it" with a senior guy directing him along the right path (eg. "Ok, now before we continue, lets write at test for this function.") It will be well worth the resources you commit to it.

Maybe also have someone in your group give the Unit Testing 101 presentation by Kate Rhodes, I think its a great way to get people excited about testing, if delivered well.

Another thing you can do is have your Jr. Devs practice the Bowling Game Kata which will help them learn Test Driven Development. It is in java, but could easily be adapted to any language.

Solution 2:

Have a code review before every commit (even if it's a 1 minute "I've changed this variable name"), and as part of the code review, review any unit tests.

Don't sign off on the commit until the tests are in place.

(Also - If his work wasn't tested - why was it in a production build in the first place? If it's not tested, don't let it in, then you won't have to work weekends)

Solution 3:

For myself, I have started insisting that every bug I find and fix be expressed as a test:

1. "Hmmm, that's not right..."
2. Find possible problem
3. Write a test, show that the code fails
4. Fix the problem
5. Show that the new code passes
6. Loop if the original problem persists

I try to do this even while banging stuff out, and I get done in about the same time, only with a partial test suite already in place.

(I don't live in a commercial programming environment, and am often the only coder working a particular project.)

Solution 4:

Imagine I am a mock programmer, named... Marco. Imagine I have graduated school not that long ago, and never really had to write tests. Imagine I work in a company that doesn't really enforce or asks for this. OK? good! Now imagine, that the company is switching to using tests, and they are trying to get me inline with this. I will give somewhat snarky reaction to items mentioned so far, as if I didn't do any research on this.

Let's get this started with the creator:

Showing that the design becomes simpler.

How can writing more, make things simpler. I would now have to keep tabs on getting more cases, and etc. This makes it more complicated if you ask me. Give me solid details.

Showing it prevents defects.

I know that. This is why they are called tests. My code is good, and I checked it for issues, so I don't see where those tests would help.

Making it an ego thing saying only bad programmers don't.

Ohh, so you think I am a bad programmer just because I don't do as much used testing. I'm insulted and positively annoyed at you. I would rather have assistance and support than sayings.

@Justin Standard: On start of new propect pair the junior guy up with yourself or another senior programmer.

Ohh, this is so important that resources will be spent making sure I see how things are done, and have some assist me on how things are done. This is helpful, and I might just start doing it more.

@Justin Standard: Read Unit Testing 101 presentation by Kate Rhodes.

Ahh, that was an interesting presentation, and it made me think about testing. It hammered some points in that I should consider, and it might have swayed my views a bit.

I would love to see more compelling articles, and other tools to assist me in getting in line with thinking this is the right way to do things.

@Dominic Cooney: Spend some time and share testing techniques.

Ahh, this helps me understand what is expected of me as far as techniques, and it puts more items in my bag of knowledge, that I might use again.

@Dominic Cooney: Answer questions, examples and books.

Having a point person (people) to answer question is helpful, it might make me more likely to try. Good examples are great, and it gives me something to aim for, and something to look for reference. Books that are relevant to this directly are great reference.

@Adam Hayle: Surprise Review.

Say what, you sprung something that I am completely unprepared for. I feel uncomfortable with this, but will do my best. I will now be scared and mildly apprehensive of this coming up again, thank you. However, the scare tactic might have worked, but it does have a cost. However, if nothing else works, this might just be the push that is needed.

@Rytmis: Items are only considered done when they have test cases.

Ohh, interesting. I see I really do have to do this now, otherwise I'm not completing anything. This makes sense.

@jmorris: Get Rid / Sacrifice.

glares, glares, glares - There is a chance I might learn, and with support, and assistance, I can become a very important and functional part of the teams. This is one of my handicaps now, but it won't be for long. However, if I just don't get it, I understand that I will go. I think I will get it.

In the end, the support of my team with play a large part in all this. Having a person take their time to assist, and get me started into good habits is always welcome. Then, afterward having a good support net would be great. It would always be appreciated to have someone come a few times afterward, and go over some code, to see how everything is flowing, not in a review per se, but more as a friendly visit.

Reasoning, Preparing, Teaching, Follow up, Support.

Solution 5:

I've noticed that a lot of programmers see the value of testing on a rational level. If you've heard things like "yeah, I know I should test this but I really need to get this done quickly" then you know what I mean. However, on an emotional level they feel that they get something done only when they're writing the real code.

The goal, then, should be to somehow get them to understand that testing is in fact the only way to measure when something is "done", and thus give them the intrinsic motivation to write tests.

I'm afraid that's a lot harder than it should be, though. You'll hear a lot of excuses along the lines of "I'm in a real hurry, I'll rewrite/refactor this later and then add the tests" -- and of course, the followup never happens because, surprisingly, they're just as busy the next week.