Why We Don't Write Tests
whatdoitest.com
Why We Don't Write Tests
1–10 of 17 posts
Re: Why We Don't Write Tests
#2I read the headline and skimmed the article. I only realised at the end, when he's trying to sell you something, that the 'we' is inclusive-marketing-speak.
Before that I thought that it was 'we (my organisation) don't write tests, and here's a defence of why', followed by a list of excuses (in which I thought 'I wouldn't touch this guy with a bargepole'). I only realised he wasn't making excuses for himself after reading the homepage.
tl;dr misleading title and confessional writing style YMMV
Re: Why We Don't Write Tests
#3In my opinion, tests should be an after-thought until your product is seeing success and heavy use.
Re: Why We Don't Write Tests
#4In my opinion, tests should be an after-thought until your product is seeing success and heavy use.
What happens when your customers' data is lost or corrupted because of a bug you could have caught?
Re: Why We Don't Write Tests
#5In my opinion, tests should be an after-thought until your product is seeing success and heavy use.
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.
Re: Why We Don't Write Tests
#6In 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."
Re: Why We Don't Write Tests
#7Earlier quoted context omitted.
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.
Re: Why We Don't Write Tests
#8In my opinion, tests should be an after-thought until your product is seeing success and heavy use.
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?
Re: Why We Don't Write Tests
#9Earlier quoted context omitted.
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.
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.
Re: Why We Don't Write Tests
#10In my opinion, tests should be an after-thought until your product is seeing success and heavy use.
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.