8 ms·

That is just gaming your coverage stats, there are still the different branches they just aren't visible now.

thaumasiotes 5y ago
That's not true. Compare `( a() || b() || c() ) ? yes() : no()` to `( a() | b() | c() ) ? yes() : no()`. In the second case, there are two paths through the code: a() b() c() yes() a() b() c() no() But in the first case, there are more paths: a() /* true */ yes() a() /* false */ b() /* true */ yes() a() /* false */ b() /* false */ c() /* true */ yes() a() /* false */ b() /* false */ c() /* false */ no() That is because there are fewer branches in the second statement (just one) than there are in the first statement (three).
- GoblinSlayer 5y ago
  The code is correct if you hit yes() and no() correctly depending on three conditions. There are 8 possibilities in both cases and thus you need 8 tests in both cases. Shortcircuiting is optimization, it doesn't reduce complexity of the logic.
  - thaumasiotes 5y ago
    That is a concern, but it's not one related to how many branches exist in the code. "How did we get here?" and "Are we in the right place?" are distinct questions.
- snovv_crash 5y ago
  So, it tests that you're running yes() and no(). But it doesn't test that your choice to use 'a()|b()|c()' for your condition was correct, instead of, for example, 'a()&b()&c()' or even '(a()&b())|c()' because you didn't test all the combinations. Using bitwise instead of logical operations hides this in your branch coverage report.
  - thaumasiotes 5y ago
    You are not attempting to have branch coverage; you are attempting to cover the space of possible inputs.
    - snovv_crash 5y ago
      You're trying to check that all of your logic is correct. That's the point of doing tests. If your test doesn't check for certain input combinations, then you haven't tested your logic completely. The point of branch coverage is to show when you missed input combinations for your logic. Artificially running all of the branches and then throwing away results just gives you a false sense of security about how much of your logic you covered. I mean, technically, using bitwise instead of short-circuiting logic doesn't have branches at an assembly code level. But this is pedantry because we're actually trying to check the logic is correct, not that our compiler can correctly translate && into the same Boolean result as &.

That's not true. Compare `( a() || b() || c() ) ? yes() : no()` to `( a() | b() | c() ) ? yes() : no()`. In the second case, there are two paths through the code: a() b() c() yes() a() b() c() no() But in the first case, there are more paths: a() /* true */ yes() a() /* false */ b() /* true */ yes() a() /* false */ b() /* false */ c() /* true */ yes() a() /* false */ b() /* false */ c() /* false */ no() That is because there are fewer branches in the second statement (just one) than there are in the first statement (three).

GoblinSlayer 5y ago
The code is correct if you hit yes() and no() correctly depending on three conditions. There are 8 possibilities in both cases and thus you need 8 tests in both cases. Shortcircuiting is optimization, it doesn't reduce complexity of the logic.
- thaumasiotes 5y ago
  That is a concern, but it's not one related to how many branches exist in the code. "How did we get here?" and "Are we in the right place?" are distinct questions.
snovv_crash 5y ago
So, it tests that you're running yes() and no(). But it doesn't test that your choice to use 'a()|b()|c()' for your condition was correct, instead of, for example, 'a()&b()&c()' or even '(a()&b())|c()' because you didn't test all the combinations. Using bitwise instead of logical operations hides this in your branch coverage report.
- thaumasiotes 5y ago
  You are not attempting to have branch coverage; you are attempting to cover the space of possible inputs.
  - snovv_crash 5y ago
    You're trying to check that all of your logic is correct. That's the point of doing tests. If your test doesn't check for certain input combinations, then you haven't tested your logic completely. The point of branch coverage is to show when you missed input combinations for your logic. Artificially running all of the branches and then throwing away results just gives you a false sense of security about how much of your logic you covered. I mean, technically, using bitwise instead of short-circuiting logic doesn't have branches at an assembly code level. But this is pedantry because we're actually trying to check the logic is correct, not that our compiler can correctly translate && into the same Boolean result as &.