5 ms·

Which ones? I’ve used at least a dozen at this point, across C++, C#, JavaScript, Rust — and all of them throw (the equivalent of) exceptions on assertion failu

Which ones? I’ve used at least a dozen at this point, across C++, C#, JavaScript, Rust — and all of them throw (the equivalent of) exceptions on assertion failures.

k__ 4y ago
My experience with testing framework was that they do all tests and then mark the ones that failed.
- carnitine 4y ago
  That has nothing to do with not knowing which assertion in a given test has failed.
jmillikin 4y ago
GoogleTest (C++) and Go's built-in testing framework both support non-fatal assertions. They're used for code like this: assert_eq(list.len(), 1) expect_eq(list[0].username, "jdoe") expect_eq(list[0].uid, 1000) The idea being that if multiple properties are incorrect, then all of them will be printed out to the test log.
- masklinn 4y ago
  That seems like it'd easily get confusing, when the assertions are dependent. Which is often the case e.g. if the list is empty, testing the properties of the first item make no sense.
  - jmillikin 4y ago
    That's why the first check is a hard assertion (returning on error), and the others are soft (continuing on error). If the list is empty, then the log will contain one error about the length being zero. If the list has one item but it has the wrong properties, the log will contain two errors.
    - masklinn 4y ago
      > That's why the first check is a hard assertion (returning on error), and the others are soft (continuing on error). See that's so completely unclear I utterly missed that there were two different calls there. Doesn't exactly help that the functions are the exact same length, and significantly overlap in naming.
      - TeMPOraL 4y ago
        That's just a matter of familiarity, though. And if you make a mistake, you'll discover it the first time the test fails - either you'll see too little output, or you'll see the test throw an exception or crash.
      - HereBeBeasties 4y ago
        I bet if it were in monospace and you were reading code in context rather than on HN you'd have noticed. That said, NUnit has much better syntax for this, where you put parallel/multiple assertions like this in an explicit block together: https://docs.nunit.org/articles/nunit/writing-tests/assertions/multiple-asserts.html https://docs.nunit.org/articles/nunit/writing-tests/assertio... Much less boilerplate duplication in the actual test framework, too.
        masklinn 4y ago
        > I bet if it were in monospace It is. > and you were reading code in context rather than on HN you'd have noticed. (X) doubt
- codeflo 4y ago
  GoogleTest was the one we used. I forgot, but now that you mention it, I remember the expect variations. We had decided against them. It’s a confusing feature in my opinion. If that’s what people mean by “multiple assertions”, then I at least understand where there coming from.

Which ones? I’ve used at least a dozen at this point, across C++, C#, JavaScript, Rust — and all of them throw (the equivalent of) exceptions on assertion failures.

k__ 4y ago

My experience with testing framework was that they do all tests and then mark the ones that failed.

carnitine 4y ago
That has nothing to do with not knowing which assertion in a given test has failed.

jmillikin 4y ago

GoogleTest (C++) and Go's built-in testing framework both support non-fatal assertions. They're used for code like this: assert_eq(list.len(), 1) expect_eq(list[0].username, "jdoe") expect_eq(list[0].uid, 1000) The idea being that if multiple properties are incorrect, then all of them will be printed out to the test log.

masklinn 4y ago
That seems like it'd easily get confusing, when the assertions are dependent. Which is often the case e.g. if the list is empty, testing the properties of the first item make no sense.
- jmillikin 4y ago
  That's why the first check is a hard assertion (returning on error), and the others are soft (continuing on error). If the list is empty, then the log will contain one error about the length being zero. If the list has one item but it has the wrong properties, the log will contain two errors.
  - masklinn 4y ago
    > That's why the first check is a hard assertion (returning on error), and the others are soft (continuing on error). See that's so completely unclear I utterly missed that there were two different calls there. Doesn't exactly help that the functions are the exact same length, and significantly overlap in naming.
    - TeMPOraL 4y ago
      That's just a matter of familiarity, though. And if you make a mistake, you'll discover it the first time the test fails - either you'll see too little output, or you'll see the test throw an exception or crash.
    - HereBeBeasties 4y ago
      I bet if it were in monospace and you were reading code in context rather than on HN you'd have noticed. That said, NUnit has much better syntax for this, where you put parallel/multiple assertions like this in an explicit block together: https://docs.nunit.org/articles/nunit/writing-tests/assertions/multiple-asserts.html https://docs.nunit.org/articles/nunit/writing-tests/assertio... Much less boilerplate duplication in the actual test framework, too.
      - masklinn 4y ago
        > I bet if it were in monospace It is. > and you were reading code in context rather than on HN you'd have noticed. (X) doubt
codeflo 4y ago
GoogleTest was the one we used. I forgot, but now that you mention it, I remember the expect variations. We had decided against them. It’s a confusing feature in my opinion. If that’s what people mean by “multiple assertions”, then I at least understand where there coming from.