Writing tests to learn the code

Question

My team is bringing on two new people - an intern and a full time. The intern has one semester to go, and the full time is fresh out of uni. After a two week training period, the plan management has for them is to have them write tests to learn the code base. (Which, if you follow my other questions you know we need tests desperately.)

But then it got me thinking... how can you write a test if you don't know what the code is supposed to actually do? I fear this would cause us to have fragile and non-thorough tests.

Regardless of how common it is, is it a good idea to have new developers write unit tests for a while to learn the code base?

Answer 1

IMHO just writing tests is a Bad idea.

If you want people to learn how to be unit testers then fine getting them to write tests for the codebase will get them experience writing tests for the codebase. The will learn how to consume the code base, and not necessarily work on the code iself.

If you want them to be actual developers, I would, instead have them fix actual bugs in the codebase and write unit tests before and after as well.

Answer 2

I had been through this when I was 4 months old in my company. To write test cases we need to read the requirements specification. I read the description of what the application is required to do along with mockup screens in the spec document which helped me to understand what the application does.

The test cases were reviewed by the Team Lead and peers to help ensure the communication is clear and the logic has been understood in the right way.

This approach would be worthwhile if expert guidance from a Subject Matter Expert (SME) is provided to the new team and all their clarifications\questions regarding what the application really does is clarified.

Answer 3

I'm kind of surprised by the approach. I have had (or seen) new employees test the code, code review, write unit tests or go through the Test Cases to understand the application and the code. I do share your concern that without good enough knowledge of the application, the tests written might be fragile. One of the issue can be that the tests might be written with too much of details, which won't be useful for the people who use the application on daily basis. Another important factor they would lack is prioritizing the tests as they might tend to follow the theoretical path.

That said, if it is an UI, and the new employees are writing automation tests, it might be a good idea to, let's say, have them create the Page Objects.

Answer 4

how can you write a test if you don't know what the code is supposed to actually do?

You probably can't. You can write tests to prove that it still does what it did when the test is written, but that has somewhat less value, I suspect.

Answer 5

It is a nice idea, as long as the new employees are willing to do it. Someone fresh out of a university, having spent their time studying compilers, language theory, operating system design, complex data structures, and complicated optimization algorithms may pale at the thought of writing something as lowly as unit tests. You and I know this stuff is important, but someone right out of school may not appreciate it.

But let's assume your new hires are open-minded and excited to be getting paid to write unit tests. You are wise to think about they should begin. Here are some things you can do to mitigate the risk you described:

1. Pick a feature for them to test.
2. Spend as much time as they need talking about the feature, describing its purpose, its trade-offs, its inputs, outputs, and configuration settings. Draw architectural diagrams. Even better, ask them describe the feature to you.
3. Ask them to draw up a test plan, then review it thoroughly.
4. Ask them to code a few tests from the test plan, then review those.

Once you've done that, you can hopefully trust them to implement the rest of the test plan.