Should I start with Unit testing when teaching a new developer?

Question

I'm currently working on a project that is using technologies like Silverlight, WCF, EnterpriseLibrary, Unity, LinqToSql, NUnit, RhinoMocks in .Net 3.5

I'm training up a new developer who has some experience with VB script and SQL, but no exposure to .Net

Almost 100% of the codebase has unit test coverage, but it just seems that getting the new dev to start writing unit tests is too much, there is enough stuff going on to get his head around, without the added confusion of unit tests and mocks.

He's been assigned with the tasks to implement new features to the solution that cut through every layer, from UI to database, and as always there's a strong customer demand to get the feature into production as soon as possible.

What do you think the best approach would be for getting someone up to speed?

Answer 1

With absolutely no .NET experience, I'd say wrapping your head around TDD at the same time as learning .NET is a bit much.

Some people with plenty of .NET experience have a hard enough time with TDD - it requires a real change in fundamental approach to development. Going from VB to .NET isn't hard but it does take time.

You really want to avoid confusion - TDD is a good way to develop, but it is not the way and TDD != .NET development. In fact, it's totally orthogonal - trying to teach a new methodology and a new platform at the same time? I can't see how that's a good idea.

Answer 2

It sounds like that new developer is already going through a trial by fire.

Seems like you should let him get up to speed and started on his share of the features, give him some time working on them and, once he's comfortable...then start him in on Unit Tests.

Answer 3

Considering there is already a lot of things to learn, I'm afraid speaking about TDD and automated testing might be a bit "too much" : if your new developper doesn't know how to develop, he will not know how to develop tests -- and the tests he'll write will probably not be really useful.

In your situation, I'd let him code for a couple of days / weeks, testing by hand ; and when he starts to understand your codebase, I'd spend some time with him, for some pair-programming : it would be a great occasion to introduce automated-testing, and review his code / comment / improve at the same time.

Answer 4

I would say yes - the entire point of tests is to get concentrated down in one area. It actually helps clear the head and its not like it takes more than 10 minutes to learn NUnit. Sure he'll probably struggle a little with the concepts for a while but a little hard work and plenty of pairing should overcome that a lot easier than throwing him assignments without the guidance that TDD provides.

Answer 5

I would say start the programmer off in support. Understanding the users issue and looking for the bug, fault finding, and fixing will teach new programmers how the application is put together, writing tests is more about new development.

Answer 6

If you have heavy mockery in your Test Area he will have serious problems to understand that. However if you would assign him simpler Tasks (where he wouldn't have to care about Mockery) and learn to find out "what should my code do?" this should be doable.

Answer 7

To an inexperienced developer, unit testing looks like doubling all of your code. It's a huge turn off.

You really need to let them fail before they can truly appreciate the benifits of unit testing.

Answer 8

If it were me, I'd pair with him and TDD for a bit. You write some test, he writes the code that makes it work then he writes the next test and you write the code to make it work, etc.

Fun, gets you experienced quickly, saves time and money.

Answer 9

I would start simple - cut up the assignment into logical parts, then pair with him until he gets a grasp of the current part. I don't think a full immersion into TDD would be effective until a good level of comfort is reached on his part, but that doesn't mean you can't expose him to unit testing and such.

Perhaps, as part of your preparation work, you could write a few tests that will be needed to accomplish the assigned task. As he is working through the problem, you could guide him towards a general solution, using the tests ("red light BAD!") to demonstrate where his thinking is off.

From there, you could "drive" while he "navigates" - he defines the desired functionality to you, and you can question him on how you might test that functionality. Begin writing the tests with him so that he can see the connection between the tests and the product, then let him slowly take over.

Hopefully, if he's a good fit, he'll be able to grasp the concepts from the ground-up, then deduct how to write his own tests (with your guidance, of course!). The final step I think would be to throw him into the pool and force him to write the tests as part of defining the functionality he wants to write.

It probably won't be a quick process, but hopefully this will give him a good grounding in TDD / unit testing

Answer 10

He's been assigned with the tasks to implement new features to the solution that cut through every layer, from UI to database, and as always there's a strong customer demand to get the feature into production as soon as possible.

What do you think the best approach would be for getting someone up to speed?

If you withold information then he may never get up to speed. Teach him how you would do the job.

As the junior member of the team, "strong customer demand" (i.e. problems with the schedule) isn't his problem: that's something the team leader and/or project manager should shelter him from.

You may need to educate the customer: that bringing on a new team member who has no previous experience with the technologies is an investment that's worthwhile in the long term.

In the short term you (or the customer rather) may see little or no immediate benefit: because he's slow (learning), and taking some of your time (not independent).

IMO you should:

• Not make him hurry (instead let him learn to do it well before you expect him to do it quickly)

• Concentrate on whatever's necessary to ensure that his output doesn't degrade the overall quality of the project's deliverables (i.e. you should certainly teach him, and ensure that his schedule allows for, whatever developer testing and quality assurance methods you expect of developers)

That said, I don't think that unit test are always necessary. But in a situation where it's a new (inexperienced) programmer, and where you had obviously already decided that 100% unit test coverage was the right thing for this project, I find it hard to see why you're thinking of changing your development process now for him (unless perhaps these features which he's been assigned have some schedule/quality requirements that are different from other features).

Answer 11

If not now then when? I think the line of reasoning I'm seeing in this discussion is an excuse for not doing unit testing. There will always be a better programmer than me, I will always be a better programmer tomorrow.

Even hinting that "only uber ninja developers" should do unit testing is the wrong message to send, especially if you value your 100% coverage stats.

Unit testing teaches one the API of the code under test backwards and forwards without making a developer learn via making dangerous untested changes to production code.

As for the complexity issue-- complex code is complex code. Cowboy development without unit tests doesn't make it simpler.

Answer 12

have someone else write the unit tests and have him write the code to make the test pass. Once he is comfortable with that, you can introduce him to creating tests.

Answer 13

What I would do is say:

"We use TDD here, which you will be doing as well, but first I want you to get comfortable with the .NET environment. Then in a couple weeks we'll sit down and code a couple unit tests together."

I think this gives him time to digest.