[Klathmon]

We use the test as a way to prove we know what the bug actually is.

Our debugging "path" normally is:

1. Find out bug exists

2. Write a test that can reproduce the bug

3. Distill that test down to the minimum needed

4. Fix bug until test passes

5. Test bug is actually fixed by trying to reproduce it the same way the user/bugreport did.

When done like that, the test isn't "extra work" but is just part of narrowing down your actual problem most of the time.

And that test (assuming it's not extremely slow to run), takes very little to maintain, so leaving it in the suite of tests is basically a positive only.

[hacker_9]

Whist I agree with this approach, sometimes it just isn't possible if the code was written in a non-testable way to begin with. Such as code that hits the database a lot or relies on network data. In this case, weighing up the ROI is a worthwhile endeavour, with a note to refactor more thoroughly at a later date.

[acjohnson55]

That's a really good reason to write business logic in a way that doesn't have those dependencies hard wired in. I often end up in those sorts of nightmares in codebases that use the active record pattern (hiding database access everywhere), hooks, critical logic in the HTTP layer, and so on.

[merb]

> Such as code that hits the database a lot or relies on network data.

well the first problem is not a problem since you can cheat it. if you rely on the native database you can actually fake your driver and insert transactions (subtransactions or in postgresql savepoints) so for the whole test suite you just rollback to the latest savepoint, this saves a lot of time. (it's actually not that hard in java+di or in languages where you can monkey patc code.