If anyone tells you unit tests are a waste of time, send them to this post.
I am in the middle of some major refactoring of our bills generator. Billing, you know, is full of lots of not-so-obvious details. E.g. I have just caught a bug where I kept only internal users instead of throwing them out and keeping only external users. Your regular ‘missing one character’ error that is almost impossible to spot by just looking at the code.
Subscriptions = Usage.Subscriptions
.Where(s=>!checker.IsUserInternalToProduct(s.User, InternalUsers))
.ToArray();
Permalink
This doesn’t look scary because this bug is hard to miss. Any testing would have revealed the problem. It’s more fun when unit test finds something which is hard to find manually. For example, if enumeration got out of sync with the database.
Permalink
> Any testing would have revealed
Well, depends on the testing 🙂 The billing process is quite complicated, so this is not trivial to spot. In fact, I would not be surprised if this went unnoticed for a month or two.
Permalink
Premature bug-fixing is the root of all evil.
Not all bugs have to be fixed at all. And most bugs that need to be fixed, should only be fixed if the effort to fix is below the potential damage.
Billing apps are associated with big potential damages, therefore investing a lot of efforts to unit test might pay off. Many other products are not so sensitive to bugs.
Permalink
Well, it’s a slippery slope. I agree in that not all bugs need to be fixed, but I use unit test not only for bugs, but to be able to refactor without fear. Unit tests allow me to take a piece of code and completely tear it apart, while I am sure it still works as intended.