Hacker News Reader

Comment by RyanZAG | Hacker News Reader

The tests are written independently of the original code. If someone has made a logic error or misunderstood some part of the spec, there is a good chance that the independent test implementation is not going to have the identical error. It's definitely a higher chance of finding bugs than having 1 developer write both, as long as the testing is written independently based on an API.

View on HN

There's a difference between code tests though and spec verification.

Spec verification is (should be...) black-box integration testing. And yes, this is a good chance to get a second set of eyes on the spec to make sure nothing was missed in the implementation. (unit-tests can't catch missing code!)

Code tests should be more white-box and should be measured against line/code coverage instead of spec coverage. These are what I think the original devs should write, and should be 95%+ of the total test volume.

The problem with expecting testing to pick up spec errors is that it takes comes at the end of the design/build phase instead of the beginning when you can make changes easily.

> Code tests should be more white-box and should be measured against line/code coverage instead of spec coverage. These are what I think the original devs should write

Nobody's stopping them.

Well you're not going to pick up spec errors with same-developer unit tests, so either you have someone else write those spec tests or you wait until the customer picks them up on initial delivery / QA.

Reply on news.ycombinator.com