My biggest issue with this kind of “TDD” is, you pay two people to write the same code twice. Test-driven can work if done correctly, but this just stupid.
I had a coworker who was obsessed with writing unit tests. He was the lead developer on a project which was supposed to take three months and at one point had gone past the two year mark without producing working code. At one point during a meeting with the increasingly (and legitimately) unhappy client, he blurted out “but we’ve written six times as much test code as actual code!” He was not exaggerating either. Believe it or not, this made the client even less happy.
I think my last programming job (a couple of years ago) had a healthy relationship to tests. You had to do meet a certain coverage percentage, and if you had particularly interesting pieces of code, they should better be tested. But they acknowledged that 100% is just stupid, and that testing the same boilerplate over and over was a waste of time.
My biggest issue with this kind of “TDD” is, you pay two people to write the same code twice. Test-driven can work if done correctly, but this just stupid.
I had a coworker who was obsessed with writing unit tests. He was the lead developer on a project which was supposed to take three months and at one point had gone past the two year mark without producing working code. At one point during a meeting with the increasingly (and legitimately) unhappy client, he blurted out “but we’ve written six times as much test code as actual code!” He was not exaggerating either. Believe it or not, this made the client even less happy.
I think my last programming job (a couple of years ago) had a healthy relationship to tests. You had to do meet a certain coverage percentage, and if you had particularly interesting pieces of code, they should better be tested. But they acknowledged that 100% is just stupid, and that testing the same boilerplate over and over was a waste of time.