Tagging unit tests with owner considered a good idea?

Question

I would like to know your opinion on whether it is a good idea to have developers put their name or signature on top of every test they write and why (not)?

Answer 1

I would say no. If you really need to know who wrote the test, you should be able to look back in your version control to see who's to blame. When people start putting their name on things, you lose the sense of collective ownership/blame, and people start to get more concerned with "their" code rather than the system as a whole.

Answer 2

I upvoted Andy's but I'd also add that putting the name in the code also is then something else that must be maintained. eg. Joe creates the test, but Jane changes it, is it Joe's test or Jane's test? And if Jane doesn't change the comment, you'll now go and talk to Joe about the code that Jane wrote... All too confusing. Use Blame and be done with it.

Answer 3

I think it depends on the attitude that already exists. If there are many conflicts, then removing all the names is useful, because the code stands for itself. However, if the names are put on the tests (as with code) then the developer is taking ownership.

Taking ownership is always a good thing because it encourages the developer to make it as perfect as possible. It also helps when you need to ask a question about the test, or if the test is failing, and you can't figure out why, you'll be able to ask the expert on the subject.

However, if there is a darker atmosphere, more about developers who are defensive, and are trying to undermine each other, then the names will cause them to focus on 'who made this code wrong' or 'this test failed because X coded it badly' rather than focusing on the error that the test might be detecting.

So there's always a balance when explicitly attaching names to tests like that. And as Andy mentioned, there's always source control if you REALLY need to know who wrote something.

Answer 4

What would you do with the information?

There's no use case for having the author's name.

Generally, the information has one of two meanings.

1. The person's gone (gone from the company, gone from the project, or a contractor and someone who'll never be found again.)

2. The person's still around.

In the second case, you already knew that. Having their name in a source code file doesn't clarify the fact that they worked on this code, are still with the company and still on the project.

So, author's name has no use cases.

Answer 5

I think it really depends on what the rest of your culture is around code ownership. If your teams culture is that all code is owned by someone, and only that person can touch that code, then labeling whose code is whose might make sense.

However, I prefer to work on teams where there's collective ownership of code. Sometimes it's nice to have an original author on a file, just to see whose original design it was, but beyond that, I don't think tagging specific tests is useful.

As other people mentioned, if you really need to figure out who made a particular change, you can figure that out from version control. In general though, I think tests should be owned and maintained by the whole team.

Answer 6

I favour self-explanatory test cases rather than signed tests.

Even if you know who wrote the test, and he's still working here, and he's available, you cannot be certain he remembers the reasons why he wrote this test.

Make sure the names of the test case are explicit enough. Add comments if necessary, reference bug ID, User Story, Customer ...