3 ms·
Assertions are most of the time completely useless and just a waste of time. If you put these assertions in one method it will break only at runtime. Usually it
by tigershark 10y ago
Assertions are most of the time completely useless and just a waste of time.
If you put these assertions in one method it will break only at runtime. Usually it is a not very used method and the code that caused the assertion to fail is shipped in production and you realise only too late that it's broken.
If you had a proper unit test instead of an assertion you would have caught the bug as soon as you pushed the code and the continuous integration kicked in.
- icebraining 10y agoWhy not put an assertion, then add a test that deliberately checks if it's triggered?
- tigershark 10y agoThe comment that I replied to was about using assertions instead of tests. You can certainly write an assertion and test it after, but unless it is absolutely necessary I would prefer to avoid polluting the code with "documentation". The right place for that is in the unit tests, not in the middle of production code.
- vectorjohn 10y agoI disagree, the right place is in the code where the functionality is defined. And the comment you replied to i didn't read as "assertions instead of tests". That's absurd. You should have tests that exercise the code that contains the assertions. It's the best of both worlds. You get code automatically tested and you get inline documentation that can't lie to you.
- brianwawok 10y agoI say code the happy path, and then have assertions. Saves writing 12 unit tests that show passing null breaks the code. No one cares about that.
- brianwawok 10y agoAnd the comment train I was on was using unit test for documentation on valid inputs and outputs. Asserts are documentations on valid inputs and outputs that very cleanly break when violated.