There is no single answer to this question. Obviously, if you’re a business with a single developer then the developer should write the tests. If you’re an organization of a thousand developers, the answer will be different.

Assuming a “normal” team with a few developers and possibly a few people dedicated to testing, it goes something like this:

1. developers write unit tests
2. developers and/or QA write integration tests
3. QA writes acceptance tests

In the scrum model, there is no distinction between “developer” and “QA”. The team as a whole is responsible for the quality of the software, and the team decides on a case-by-case basis who should be doing the testing.

Many smart people think developers should write all their tests. I’ve worked in organizations like that, and we always delivered exceptionally high quality software. In those companies, not only should senior devs write tests, they must.

Other very smart people believe that developers should not test their own code because they have blinders on. “I don’t need to test X, my changes couldn’t possibly have affected it”. To combat that you should always have someone else write the tests. I’ve worked in those types of organizations, and there, too, we also delivered high quality code.

The bottom line is that if you’re a developer, you are ultimately responsible for the quality of the code you produce. That means you should be writing tests — regardless of organizational structure — and if you have other team members, then you should work with them to make sure the code is properly tested.

In practical terms, the only people who can answer this for you is you and your team. It’s perfectly reasonable for senior level programmers to write tests (and if they are good programmers, you won’t ever have to ask them to do it because that’s just part of the job). It’s also perfectly reasonable for junior people to write tests — this is a good way for them to learn the software.

In either case, there is no should. You should do whatever allows your team to create software with an appropriate level of quality.

Edit: I read the title as unit tests:

I have heard this idea before, and IMHO I think it is a terrible idea to force unit testing solely on junior developers.

You would be creating an unnecessary division in your team.

Developers should write unit tests for their own code. Both the code and unit tests will then in the future be updated by other developers as features changes and bugs are discovered depending on resource availability.

Not trusting juniors with real features is not the best way to manage projects. Start them on smaller or easier features, let them unit test them, and they can work their way up to bigger, harder features.

Ideally, in test driven design, the test is written before a single line of code is written. Someone writes the failing test, someone writes the code (that passes).

In this model, it doesn’t matter too much who writes the test (or who does the code). What is required is that the test accurately describes the functionality to be written before writing code. If this understanding of the requirements requires a senior programmer, then that is who writes it.

However, once the test is written, if it was well written, anyone should be able to write the code for it that passes the test. If anything, this points to that seniors should be writing the all tests and then delegating out the coding of the guts of the code to other people who can do it.

After the fact unit testing is.. less than ideal. Unfortunately, when this happens this is often left to the juniors to “get the required coverage.” Such endeavors are often difficult because they are tedious and don’t fully test the code in question (leaving bugs that get scapegoated on the person who wrote the test for not catching it).

It is great having junior programmers gain experience with the code base. Forcing them to write after the fact unit testing isn’t the way to do it.