Hacker News Reader

Comment by hamstercat | Hacker News Reader

Doesn't that just mean that the tests were effective? The goal of doing a test for each bug is to prevent them from happening again. Unless you meant that this project didn't apply this particular advice but was getting away with it just fine?

I personally believe that this advice is one of the most important one actually for a very specific reason: it leaves a very bad impression to client when a bug keep happening again and again after being fixed. Unfortunately I've lived this experience when I was just starting out in my career on a similar project (around 45-50 developers) with basically no tests at all. It wasn't fun explaining to the client, even if they were internal to the company, that the bug we fixed last month had to be fixed again.

View on HN

>Doesn't that just mean that the tests were effective?

Only in the sense that:

- What's this?

- A device that keeps tigers away.

- But there are no tigers in Los Angeles!

- See how effective it is?

>The goal of doing a test for each bug is to prevent them from happening again. Unless you meant that this project didn't apply this particular advice but was getting away with it just fine?

No, he means that they had code to test for the presence of fixed bugs, but nobody reintroduced said bugs and triggered that bug catching test code ever. So even if they didn't have the code, the end result would have been the same.

How would you know? If code is failing tests, it doesn’t leave my laptop.

Because parent said they tracked the test suites.

Perhaps the tests don't run on the devs laptop, but on an integration system (we have such a setup).

(And of course you can make test suites report failures centrally, whether they tests run on a laptop or not).

They said they tracked bugs. A test failure during development doesn’t generally go in the bug tracker.

We tracked all bugs in a custom made bug tracker: - Unit/Integration tests - Failures reported by QA - Bugs in production

Integration tests were really heavy, and ran multiprocess on a server. So locally we would run the unit tests, and relevant integration tests. The rest was tested on the integration server, which automatically created bugreports when something failed.

> - But there are no tigers in Los Angeles!

Except that there are, and are kept from terrorizing the population by very effective devices: iron cages. (iirc there is at least one Sumatran tiger in the LA zoo)

> Doesn't that just mean that the tests were effective?

Very effective. Especially if you consider that there weren't any ;). You can't get any better ROI of zero effort! ;)

Each project is different of course, and if you saw this in your project, than it would probably make sense to implement them.

But all I'm saying is that this shouldn't be a hard rule. Look at the project, look at the current issues, track your bugs, and draw your own conclusions.

Reply on news.ycombinator.com