Timeline for Are asserts or unit tests more important?
Current License: CC BY-SA 2.5
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 11, 2010 at 9:15 | comment | added | user131 | why is it not better to handle typical but often uncommon (in the eyes of the user) issues rather than assert that they should not ever happen? I fail to realize this wisdom. Sure, assert that a prime generator returns a prime, which takes a bit of extra work, which is expected in debug builds. Asserting something that a language can natively test for is just, well, stupid. Not wrapping those tests in another switch that can be turned off a few months after a release, even more stupid. | |
| Nov 11, 2010 at 8:42 | comment | added | Dominique McDonnell | @Frank Shearar, very true. You still should be failing hard at the earliest detected error state in production. Sure the users are going to complain, but that's the only way you are going to make sure that the bugs are going to get fixed. And it's a whole lot better to get a blah was 0 than a memory exception for dereferencing null a few function calls later. | |
| Nov 11, 2010 at 7:45 | comment | added | Frank Shearar | And here I think production code's the place that needs the asserts the most, because it's in production where you will get inputs that you didn't think possible. Production's the place that drives all the hardest bugs out. | |
| Nov 11, 2010 at 5:18 | comment | added | user131 | @DominicMcDonnell Well, 'should be true' statements. I sometimes assert to get around compiler quirks, such as certain versions of gcc that have a buggy abs() built in. The important thing to remember is production builds should have them turned off anyway. | |
| Nov 11, 2010 at 5:08 | comment | added | Dominique McDonnell | That's why assertions are for always supposed to be true statements, not error testing. | |
| Nov 11, 2010 at 4:45 | history | answered | user131 | CC BY-SA 2.5 |