5 ms·

I use assert, but I feel like effort writing assertions in production code could be spent writing any and/or more thorough automated tests. Even if the tests ar

by gleenn 3y ago

I use assert, but I feel like effort writing assertions in production code could be spent writing any and/or more thorough automated tests. Even if the tests are slow, you won't affect production speed. You usually can test far more in depths than verifying things inline in functions. You also wouldn't have the problem the OP mentions about not realizing that Intellij was by default not running with assertions enabled which could easily be dangerous. Just write real tests!

pacaro 3y ago
I don't see this as either or. Good quality asserts can be very effective when managing objects with complex state transitions For me assertions are for invariants. The code has no expectation of successful execution I also like (borrowing from testing) the idea of expects, where we can hope that the object is in a specific state, but have an explicit compensation path for when it isn't, perhaps objects that need to be migrated to a new schema etc.
usefulcat 3y ago
Inline assertions do have one big advantage over tests: context. They're right there in the very place where the condition must hold. For that reason, I have long thought of assertions as 'comments with teeth'. Also, inline assertions can be enabled any time, not just when running unit tests. Of course in theory that last bit shouldn't make any difference, but then I'm sure you've already heard the old joke about the difference between theory and practice..
- lelanthran 3y ago
  > I'm sure you've already heard the old joke about the difference between theory and practice.. It's not a joke, it's a fact of life that we learn soon after graduating, and then relearn again, and again, and ...
Buttons840 3y ago
Asserts are essentially checked comments and an automated test is not a replacement for comments. I've done things like the following many times: if (x != 5) { ... 40 lines here ... } else { assert(x == 5); ... more lines ... } The main purpose of the assert is to remind the reader that x == 5. There was a time where I would use a regular comment for a reminder like this, but since it's something the computer can check, I mine as well turn my regular comment into a checked comment.
- kccqzy 3y ago
  The danger is change. What if someone comes and then due to a new business requirement changes the code to if (x != 5 && x != 6) { ... 40 lines here ... } else { assert(x == 5); ... more lines ... } Because of the 40 intervening lines the person might never see your assertion! If you work in a project with automated tests that do not have sufficient coverage, this is just a spectacular way of blowing up production. Assertions are bad because they are checked at runtime which is too late. The ideal checked comment should have the checks happen at compile time. Something like Liquid Haskell.
  - Terr_ 3y ago
    > blowing up production. I prefer what Java does: Assertions are disabled at runtime by default, however you can turn them on without requiring a different code-release and you can even do it for specific packages/classes. So you might even use them in production: If feature X is already failing in some bizarrely uninformative way, turning on assertions in relevant code may provide you a better hint to what's going awry.
  - spc476 3y ago
    Then the assert() triggers and you fix the assert() (or the bug). What's the issue here?
    - kr0bat 3y ago
      In this example the assert is less explanatory than a comment. Why do if (condition): ... else: assert(!condition) ... When you could instead if (condition): ... else: #if (condition) ... Or otherwise explicitly comment the condition that was checked earlier. At least then if the comment is unchanged, whoever is touching your code will assume the comment is outdated, rather than assuming that you're asserting that x should be some undocumented magic number.
  - nerdponx 3y ago
    > If you work in a project with automated tests that do not have sufficient coverage, this is just a spectacular way of blowing up production. Great, I'd rather have this error cause a loud and obvious failure that can be easily hotfixed, than have it lead to subtly incorrect behavior that goes unnoticed for days and takes another day to debug.
indigoabstract 3y ago
Unit tests are complementary to assertions, they don't supersede them. I feel that assertions are the first line of defense against programming judgement errors/omissions and are much easier to write in the given context than unit tests.
diogenes4 3y ago
> effort writing assertions in production code Presumably the assert is used because it doesn't consume resources (ie effort) to write. Testing takes a lot of effort.
0xDEAFBEAD 3y ago
Seems to me that asserts are a force multiplier on tests. If you have a bunch of asserts, every test case you write is extra valuable -- you aren't just verifying correct input/output behavior, you're also verifying that all asserts held. In the extreme case, I can imagine ditching all your small-scale unit tests for a combination of asserts and end-to-end integration tests.
flohofwoe 3y ago
In C and C++ at least, asserts are also hints for the static analyzer (for instance that a pointer isn't expected to be null). It's better to do both, asserts and tests are not mutually exclusive, they complement each other.

by gleenn 3y ago

pacaro 3y ago

I don't see this as either or. Good quality asserts can be very effective when managing objects with complex state transitions For me assertions are for invariants. The code has no expectation of successful execution I also like (borrowing from testing) the idea of expects, where we can hope that the object is in a specific state, but have an explicit compensation path for when it isn't, perhaps objects that need to be migrated to a new schema etc.

usefulcat 3y ago

Inline assertions do have one big advantage over tests: context. They're right there in the very place where the condition must hold. For that reason, I have long thought of assertions as 'comments with teeth'. Also, inline assertions can be enabled any time, not just when running unit tests. Of course in theory that last bit shouldn't make any difference, but then I'm sure you've already heard the old joke about the difference between theory and practice..

lelanthran 3y ago
> I'm sure you've already heard the old joke about the difference between theory and practice.. It's not a joke, it's a fact of life that we learn soon after graduating, and then relearn again, and again, and ...

Buttons840 3y ago

Asserts are essentially checked comments and an automated test is not a replacement for comments. I've done things like the following many times: if (x != 5) { ... 40 lines here ... } else { assert(x == 5); ... more lines ... } The main purpose of the assert is to remind the reader that x == 5. There was a time where I would use a regular comment for a reminder like this, but since it's something the computer can check, I mine as well turn my regular comment into a checked comment.

kccqzy 3y ago
The danger is change. What if someone comes and then due to a new business requirement changes the code to if (x != 5 && x != 6) { ... 40 lines here ... } else { assert(x == 5); ... more lines ... } Because of the 40 intervening lines the person might never see your assertion! If you work in a project with automated tests that do not have sufficient coverage, this is just a spectacular way of blowing up production. Assertions are bad because they are checked at runtime which is too late. The ideal checked comment should have the checks happen at compile time. Something like Liquid Haskell.
- Terr_ 3y ago
  > blowing up production. I prefer what Java does: Assertions are disabled at runtime by default, however you can turn them on without requiring a different code-release and you can even do it for specific packages/classes. So you might even use them in production: If feature X is already failing in some bizarrely uninformative way, turning on assertions in relevant code may provide you a better hint to what's going awry.
- spc476 3y ago
  Then the assert() triggers and you fix the assert() (or the bug). What's the issue here?
  - kr0bat 3y ago
    In this example the assert is less explanatory than a comment. Why do if (condition): ... else: assert(!condition) ... When you could instead if (condition): ... else: #if (condition) ... Or otherwise explicitly comment the condition that was checked earlier. At least then if the comment is unchanged, whoever is touching your code will assume the comment is outdated, rather than assuming that you're asserting that x should be some undocumented magic number.
- nerdponx 3y ago
  > If you work in a project with automated tests that do not have sufficient coverage, this is just a spectacular way of blowing up production. Great, I'd rather have this error cause a loud and obvious failure that can be easily hotfixed, than have it lead to subtly incorrect behavior that goes unnoticed for days and takes another day to debug.

indigoabstract 3y ago

Unit tests are complementary to assertions, they don't supersede them. I feel that assertions are the first line of defense against programming judgement errors/omissions and are much easier to write in the given context than unit tests.

diogenes4 3y ago

> effort writing assertions in production code Presumably the assert is used because it doesn't consume resources (ie effort) to write. Testing takes a lot of effort.

0xDEAFBEAD 3y ago

Seems to me that asserts are a force multiplier on tests. If you have a bunch of asserts, every test case you write is extra valuable -- you aren't just verifying correct input/output behavior, you're also verifying that all asserts held. In the extreme case, I can imagine ditching all your small-scale unit tests for a combination of asserts and end-to-end integration tests.

flohofwoe 3y ago

In C and C++ at least, asserts are also hints for the static analyzer (for instance that a pointer isn't expected to be null). It's better to do both, asserts and tests are not mutually exclusive, they complement each other.