How to make junior programmers write tests? [closed]

Answer 1

Assign them to projects that don't require "top quality stable code" if that's your concern and let the jr. developer fail. Have them be the one to 'come in on the weekend' to fix their bugs. Have lunch a lot and talk about software development practices (not lectures, but discussions). In time they will acquire and develop the best practices to do the tasks they are assigned.

Who knows, they might even come up with something better than the techniques your team currently uses.

Answer 2

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.

Answer 3

As a junior programmer myself, I thought that Id reveal what it was like when I found myself in a similar situation to your junior developer.

When I first came out of uni, I found that it had severly un equipped me to deal with the real world. Yes I knew some JAVA basics and some philosophy (don't ask) but that was about it. When I first got my job it was a little daunting to say the least. Let me tell you I was probably one of the biggest cowboys around, I would hack together a little bug fix / algorithm with no comments / testing / documentation and ship it out the door.

I was lucky enough to be under the supervision of a kind and very patient senior programmer. Luckily for me, he decided to sit down with me and spend 1-2 weeks going through my very hacked togethor code. He would explain where I'd gone wrong, the finer points of c and pointers (boy did that confuse me!). We managed to write a pretty decent class/module in about a week. All I can say is that if the senior dev hadn't invested the time to help me along the right path, I probably wouldn't have lasted very long.

Happily, 2 years down the line, I would hope that some of my collegues might even consider me an average programmer.

Take home points

1. Most Universities are very bad at preparing students for the real world
2. Paired programming really helped me. Thats not to say that it will help everyone but it worked for me.

Answer 4

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.)

Answer 5

He's already doing this. Really. He just doesn't write it down. Not convinced? Watch him go through the standard development cycle:

• Write a piece of code
• Compile it
• Run to see what it does
• Write the next piece of code

Step #3 is the test. He already does testing, he just does it manually. Ask him this question: "How do you know tomorrow that the code from today still works?" He will answer: "It's such a little amount of code!"

Ask: "How about next week?"

When he hasn't got an answer, ask: "How would you like your program to tell you when a change breaks something that worked yesterday?"

That's what automatic unit testing is all about.

Answer 6

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)