Another pet peeve of mine is unit testing. Oh there’s nothing wrong with it; I recommend it highly, but clueless managers and HR people see the word “test” and think “Ah,ha – This is something testers do.”
Wrong. Unit tests by definition are developer run tests. Period. If a tester is supposed to perform unit testing, tell me how that fits in to the SDLC. This is made even funnier if you consider TDD (Test-Driven Development).
So here’s an odd thing: I came across a job listing from a testing company that is looking to hire and train the right people for testing. Sounds good to me. But then they state “dedication to unit testing code before or during application or service development.” OK, now it sounds like they’re screwed up.
Later they add “ability to…run and report Developer’s unit testing.” Well, OK – the developer writes the tests and you run them. Sounds bizarre to me, but perhaps these are not automated unit tests, but I think we’ll see Bigfoot before we see developers documenting their unit tests.
To recap: This company specializing in software testing should know that unit tests are not the responsibility or domain of testers, but they don’t. Then they back-off, saying testers should execute dev-written unit tests, but then they come back around saying they will train the right people to write unit tests.
Now it wouldn’t be a bad idea to teach testers how to read unit test code – again, assuming unit tests are actual code, not English test cases. In this case, testers could review developers’ unit tests to get an idea of the breadth and depth of the unit testing being performed. That would be good, but in my experience, unit testing was only given lip service and any unit testing that was claimed to be performed, wasn’t in code (like JUnit or NUnit) – so who knows if any unit testing was really done.
That is the nice thing about have automated unit tests – there are artifacts to examine.