4 ms·

Regarding assertions: The sections "If you think you're using enough assertions, you're wrong" and "Bonus: Sanity Checking" can be considered a subset of "Desi

Regarding assertions: The sections "If you think you're using enough assertions, you're wrong" and "Bonus: Sanity Checking" can be considered a subset of "Design by Contract"[0]. Regarding: However, comments can become out-of-date, and you might not be lucky enough to stumble across the right comment before you embark on a refactoring adventure. Not if comments are treated as first-class citizens, just as important as the code change(s) which make them out-dated. Better still is to ensure unit tests are "executable documentation"[1]. Regarding "Prefer end-to-end tests": In my experience, this leads to unit test atrophy, degrading system verification to rely solely on integration tests ("end-to-end tests"). This has often resulted in higher coupling and always resulted in interminable build times. 0 - https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract 1 - https://softwareengineering.stackexchange.com/questions/154615/are-unit-tests-really-used-as-documentation https://softwareengineering.stackexchange.com/questions/1546...

forgotmypw17 3y ago
A comment with first class citizen status is an assert?
- sideshowb 3y ago
  I've never seen an assert explain why
  - tleb_ 3y ago
    The signature for static_assert(3) in C has a second argument that is `char *msg`. With C23 onwards, it becomes optional.
    - marginalia_nu 3y ago
      Java has this too. assert isSorted(array, start, end) : "The input array for binary search is expected to be sorted"; That said, I think in many cases asserts tend to be fairly self-evident, they typically just list the invariants, e.g. assert start <= end; assert (end - start) % stepSize == 0; // some logic assert pos - start >= 0; assert pos - end < 0; assert (pos-start) % stepSize == 0; return pos;
      - bravura 3y ago
        I use it in python all the time: assert x.shape == y.shape, f"{x.shape} != {y.shape}"
        tpoacher 3y ago
        This should be # Confirm that x.shape == y.shape assert x.shape == y.shape, f"{x.shape} != {y.shape}" ## x.shape was not y.shape /s
- timeon 3y ago
  kind of: https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html https://doc.rust-lang.org/rustdoc/write-documentation/docume...
- tpoacher 3y ago
  Some languages (e.g. D), have contract blocks built into the language, which are even better. (or, well, different).
MoreQARespect 3y ago
End to end tests by definition are more loosely coupled. They are better as executable documentation - mapping to actual user flows and able to generate docs (videos, screenshots, etc.). They're slower, but it's easy enough to parallelize and cache. Unit tests will often just mirror the behavior of the code. This is not useful.
- sverhagen 3y ago
  Agree a lot. Just want to say, since the article also touched on this, that parallelization of test execution can again introduce nondeterministic failures...
- Kinrany 3y ago
  > End to end tests by definition are more loosely coupled. Can you explain how?
  - williamdclt 3y ago
    They make no assumption as to the implementation of the thing, they test that the observable behaviour is correct and that’s it. You could refactor the whole codebase without touching your tests: the tests are decoupled from the runtime code
- marginalia_nu 3y ago
  I think it depends a lot on the nature of the code. I prefer to use unit tests to probe tricky parts of the code. It's basically like a recyclable debugging session. Sometimes with an actual debugger attached, but otherwise just an assertion is fine. If I've had reason to investigate the code once there's probably a reason to keep that inspection hatch because bugs rarely come alone. Unit tests for the sake of unit tests is kinda stupid though and can actually border on a sort of technical debt. If no matter what you change, you need to fix/disable a bunch of unit tests, failing tests becomes expected and it becomes very easy to fall into just fixing the assertions or disabling the test when that happens without actually thinking about why it fails. Not even mentioning how much this sort of code base will bog down the rate of change. That said, it's a tricky balance. You can definitely have both too many and too few unit tests.

forgotmypw17 3y ago

A comment with first class citizen status is an assert?

sideshowb 3y ago
I've never seen an assert explain why
- tleb_ 3y ago
  The signature for static_assert(3) in C has a second argument that is `char *msg`. With C23 onwards, it becomes optional.
  - marginalia_nu 3y ago
    Java has this too. assert isSorted(array, start, end) : "The input array for binary search is expected to be sorted"; That said, I think in many cases asserts tend to be fairly self-evident, they typically just list the invariants, e.g. assert start <= end; assert (end - start) % stepSize == 0; // some logic assert pos - start >= 0; assert pos - end < 0; assert (pos-start) % stepSize == 0; return pos;
    - bravura 3y ago
      I use it in python all the time: assert x.shape == y.shape, f"{x.shape} != {y.shape}"
      - tpoacher 3y ago
        This should be # Confirm that x.shape == y.shape assert x.shape == y.shape, f"{x.shape} != {y.shape}" ## x.shape was not y.shape /s
timeon 3y ago
kind of: https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html https://doc.rust-lang.org/rustdoc/write-documentation/docume...
tpoacher 3y ago
Some languages (e.g. D), have contract blocks built into the language, which are even better. (or, well, different).

MoreQARespect 3y ago

End to end tests by definition are more loosely coupled. They are better as executable documentation - mapping to actual user flows and able to generate docs (videos, screenshots, etc.). They're slower, but it's easy enough to parallelize and cache. Unit tests will often just mirror the behavior of the code. This is not useful.

sverhagen 3y ago
Agree a lot. Just want to say, since the article also touched on this, that parallelization of test execution can again introduce nondeterministic failures...
Kinrany 3y ago
> End to end tests by definition are more loosely coupled. Can you explain how?
- williamdclt 3y ago
  They make no assumption as to the implementation of the thing, they test that the observable behaviour is correct and that’s it. You could refactor the whole codebase without touching your tests: the tests are decoupled from the runtime code
marginalia_nu 3y ago
I think it depends a lot on the nature of the code. I prefer to use unit tests to probe tricky parts of the code. It's basically like a recyclable debugging session. Sometimes with an actual debugger attached, but otherwise just an assertion is fine. If I've had reason to investigate the code once there's probably a reason to keep that inspection hatch because bugs rarely come alone. Unit tests for the sake of unit tests is kinda stupid though and can actually border on a sort of technical debt. If no matter what you change, you need to fix/disable a bunch of unit tests, failing tests becomes expected and it becomes very easy to fall into just fixing the assertions or disabling the test when that happens without actually thinking about why it fails. Not even mentioning how much this sort of code base will bog down the rate of change. That said, it's a tricky balance. You can definitely have both too many and too few unit tests.