Hacker News Reader

Comment by a3voices | Hacker News Reader

In my opinion, tests should be an after-thought until your product is seeing success and heavy use.

A year ago, I would have agreed with you. There's nothing stopping you from building a successful product without writing tests. Since I built the habit of writing tests, though, It definitely makes a difference, especially if you're working with a team or contractors.

Tests are a super helpful way to say "See, this works. Make sure it keeps working, everyone."

You're not afraid that some actual/potential users might be scared off from your product due to defects they encounter while using/trying the product?

I would manually test every aspect of it, and make sure there are no known defects. So any defect found by a customer would likely be some obscure edge case.

What happens when your customers' data is lost or corrupted because of a bug you could have caught?

Data redundancy in multiple locations and good logging can fix that problem better that tests, I think. Most bugs can be found anyways during development without coded tests.

For a very narrow range of software, I suppose. Not for software that has side-effects and actually does stuff in the real world.

What about software that sends emails to people, or places orders, performs billable work, or gives people directions, or supplies them with data that they then carry forward and use in decisions or in other systems?

And are you proposing that instead of writing tests you write a play-back-able-log system that can roll back state and re-apply transformations if a given component did incorrect things?

I think sensible testing is the way forward, where sensible is appropriate to the type of application, language and requirements. 100% coverage is suitable for industrial code and 1% coverage is appropriate for toy projects. But no tests at all seems foolhardy.

Not sure what you mean by "coded" tests, but I agree that most bugs can be found during development - unfortunately, my experience is that that's rarely the case. But if your development team finds most bugs during development, my hat's off to you.

By coded test, I meant taking time to write test scripts. I assumed this is what is meant by the article.

If your data transformations are bugged, you've merely succeeded in duplicating redundantly the wrong answer--backups won't save you.

That's not going to save you from failing to capture key records, or capturing them incorrectly.

You do have a point about manual testing being just as effective as automated testing, just a lot more time consuming.

Reply on news.ycombinator.com