Should testers write "unit tests"?

"Some software is very difficult to test manually. In these cases, we are often forced into writing test programs."

A few weeks ago, one of the devs on my team went to the Patterns and Practices Summit where he heard James Newkirk say that testers should write unit tests. For some reason writing unit tests is a very seductive idea to me (because I enjoy it?), but I have a gut feel that testers shouldn't write them. I worry that it shifts a responsibility from the devs to the testers that the devs should reserve. Shouldn't the author of the code unit test it?

At PNSQC, Michael Bolton said that unit testing is "confirmatory testing". It is testing that is looking to prove that things work like the author intended and everything is fine. A unit test author doesn't want to see things go wrong. They want to see things go right, keep that bar green! A tester would want to see a red bar. This positive attitude is fine, as long as those involved are aware of this dynamic.

In the meeting I spoke up and said I wasn't sure about testers writing unit tests. The dev manager then described what I would call a functional test and said he thought testers writing this type of test would be fine.

Right away, we run into terminology issues which make taking about "unit testing" harder than it might otherwise be.

What is the definition of a "unit test"?

*A test that verifies the behavior of some small part of the system?

*A developer or programmer test. Contrast with a customer test.

"In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application."

Tests that the devs write such that the "...units being tested are a consequence of the design of the software, rather than being a direct translation of the requirements."

Now I'm confused. Since I'm not totally sure what a unit test is, how do I know that testers shouldn't write them? Hmm.

Well, I think of classic unit tests where the author writes some code, has some methods, and if it is OO software, some classes as a result, and then writes standard tests for those. Good solid tests like invalid values, boundary tests, that kind of thing. This seems like stuff the dev should write.

Stepping away from this, what about when you start to combine some subsystems and you are analyzing larger functionality that might be recognizable to a customer as at least a small part of the functionality they are expecting the software to provide to them? This starts to seem like it would be fair game for the testers to write this type of test. Are these unit tests? I don't think they are, at least not against what I think is the current understanding of unit tests. Maybe where SDETs are common, this type of boundary is understood better and they don't worry about it. Elsewhere, I think it is a gap that might often be missed.