Senior Developers and Unit Tests - Required? Are they allowed to use lackeys?

Question

Should senior developers be exempt from unit testing - or should they be allowed to use lackeys to implement them? What's the best way to motivate people who are not used to using unit testing techniques to adopt them?

Answer 1

Absolutely not; at the very least because it's so much easier to write tests for code you yourself develop. But it is important for all developers, regardless of seniority, to unit-test all their code; if they develop knowing their code must be testable the fruits of their labour will be much greater.

If you need to motivate developers into unit-testing just press home the advantages and the time that will be saved in the long run. If they get into the habit of writing unit-tests for their code they'll soon start doing it as a matter of course.

Answer 2

I think having lackeys do unit tests for someone else is destroying the point of having unit tests to begin with. The programmer who writes code should know how the code should break and what its expected behavior is. Just because someone else does does not release the original programmer from that responsibility.

(Awkward phrasing due to gender neutrality.)

MSN

Answer 3

If you are a senior developer, it's in part because you are experienced enough to know that unit testing is a great development practice that helps you produce better software

Answer 4

I would argue that from a TDD purist standpoint (i.e. one that thinks that unit tests should be written before implementation), senior developers should be writing more unit tests than lackeys, not less.

The reason being that since unit tests come first, writing them requires intimate knowledge of the code base. If you let the lackeys write them, you're essentially letting those who know the least about your domain dictate the structure of your code base. That sounds like a bad idea to me.

Answer 5

The person writing the test = defining how the system should work = the "boss"

The people implementing the tests are the so called "lackeys"

Sounds like a case of an old dog who doesn't like new tricks. And as the saying goes, it's tough to get them to change... TFD (test-first development) is very fun once you start doing it, maybe have an internal 1-day workshop on TDD or TFD involving the whole team.

Answer 6

I think one possible way of handling these situations would be the Senior Developer could write the majority of the Unit Tests. That means they are defining and designing the way the program should work. The lackeys can then write the code to match the test, learning the design philosphies of the senior guy while they are at it.

Answer 7

If a senior developer isn't doing their own testing, then they're not a senior developer.

A lack of willingness to test is almost always a sign of laziness or ineptitude (or both), and neither is a trait that should be found in a senior developer.

The only scenario I can think of where it would be appropriate for a senior developer to have someone else write their unit tests would be in the case where a junior new hire is being brought up to speed on things. It could be a good task for getting their feet wet while writing some code.

Answer 8

Should senior developers be exempt from unit testing

Absolutely not. They should not be senior developers at all then. Senior developers should be leaders showing the way, the idea that lackeys do it seems absurd - why bother testing at all then.

Answer 9

Part I (Senior Developers and Unit Testing)

When I think of TDD or Test Driven Design, the Unit Tests serve the purpose of driving out the evolutionary design of the system, hopefully ensuring continuous improvement.
Writing the test shapes the code or highlights issues with a decision that has already been made, hopefully resulting in a refactoring process to increase the quality of design.

In my experience, the senior developer is normally the person with the most experience and ability, which means that they should be in a better position to spot these refactoring opportunities. (Detect the code smells)

There are three situations I can think of, off the top of my head, where someone else writing the tests for you could be acceptable.

1. Acceptance Tests/Customer Tests/End To End Tests. Call them what you will, but I mean the tests that start at the data input point, (web service, web page, application screen input), and traverse the entire stack of the system, (to a database, call to another service, back round to the input results screen etc). This could be written by someone who is not implementing the details of the individual units that will be exercised by the tests.

2. Paired Programming (Ping Pong Pattern) -

   A writes a new test and sees that it fails.
   B implements the code needed to pass the test.
   B writes the next test.
   A implements it.

3. Bug Fix Tests - When a bug is found, it is often good practice to write a failing test that exposes the defect. Once this test is in place it is entirely possible that someone implements the code that makes the test pass. I don't think that this is all that good an idea as the act of writing the test that fails due to the defect often gives some insights as to how a fix might be produced.

In short my answer to your first question would be, no a senior developer should not be exempt from writing unit tests.

Part II (Motivating people to write tests)

This is something that I have had problems with in the past. Even though I now try and perform TDD as often is appropriate, it took me a few months to see that there was a real benefit to writing tests.
I believe that trying to show others the benefits of TDD and Unit Testing is quite difficult. It is only when the person experiences for themselves, that 'ah ha' moment when TDD/Unit Tests have highlighted a subtlety in their code, that they might have otherwise missed, or helped them fix a bug in short amount of time, that they see the benefits. Getting them to that point can be quite difficult.
Personally I got there by pair programming in the aforementioned Ping Pong Pattern, working with an experienced TDDer and seeing the code we were writing to solve a non-trivial piece of functionality evolve into what might be called an elegant solution. Followed by that piece of work making it through QA and into the Live Environment without any defects raised against it.

In short, I think that pairing with an experienced programmer who is already convinced of the benefits that come from writing Unit Tests is a great way to help someone become motivated to writing unit tests.

Answer 10

One of the largest benefits of unit tests are the immediate feedback which tell you how well you are doing. If you outsource the implementation of your tests, you will get no feedback if your design works or not. And the people struggling with a bad design have no means to correct it.

Answer 11

I don't subscribe to the religion of TDD, but I do see a lot of value in unit/etc testing, and do it a lot as I code.

The point is though, nobody really knows what the code is supposed to do except the person who wrote it, and often they don't even know either.

With that in mind, you're not going to get much value out of 'lackeys' writing the tests because

1. They won't have an in-depth understanding of all the subtle corner cases
2. They won't care about the code because they have nothing invested in it
3. They will feel like they're being treated like idiots.

Even if they ARE idiots, nobody likes to be treated like one. If you want your staff to quit, this is a good way to encourage them.

Answer 12

Well I would say yes but only if the lackey is than allowed to let the fixing of found bugs over to the senior. That will teach him.

Answer 13

No one should be exempt from writing unit tests. All developers need to be able to write them, and unit tests should be reviewed as part of your code review process, as well. The complexity of the unit tests will usually be a function of the skill of the developer - with the more complex code going to more senior developers, hence the more complex and larger number of unit tests going to them, as well.

If you have one or more developers that are not able to adapt, you should try giving them some one on one assistance and pair developer the unit tests until he or she starts to get the hang of it. There is nothing technically complex enough that someone who can write code is unable to produce unit tests. If that does seem to be the case, it is probably a precursor to a larger problem with that person's skillset.

I personally think that it is also helpful for testers to be able to at least understand the unit tests that are part of the project. Collaboration between developers and testers is very important in correctly diagnosing and fixing defects. I wouldn't expect them to have to write them, but they should be able to sit with a developer and go over the concept of why/how a test is failing or not.