3 ms·

I've seen developers writing tests with no assertions, or with assertTrue(true). Always green, with 100% coverage! The same people have been asking: why should

I've seen developers writing tests with no assertions, or with assertTrue(true). Always green, with 100% coverage! The same people have been asking: why should I write tests if I can write new features? And then one senior QA comes and destroys everything. Once I found that if I press f5 50 times during a minute then backend will go in outOfMemory while spinning requests to the database.

kcb 3y ago
That's why the dev teams tests and the QA teams tests are not mutually exclusive.
- ponector 3y ago
  Testing is continuous multilayered multistaged process. Testing should start before first developer wrote first line of code for the project. Architecture blueprints, set of requirements should be tested as early as possible. But that is not happening in real life, only in books. In real life pm will bring cheap contractor from India one month before the target release date.
feoren 3y ago
> I've seen developers writing tests with no assertions This can be OK if the code executing without throwing exceptions is itself testing something. If you have a lot of assertions written directly into the code, as pre- or post-conditions for instance. But I'm guessing that wasn't the case here.
- WrongAssumption 3y ago
  Why would it be ok to not test the assertions would be triggered if the conditions are bad? How would you verify that the assertions are correct with just a happy path? If you run a code with pre-post assertions, then remove all the assertions the same test will continue to pass.
  - feoren 3y ago
    Agreed: such tests are not sufficient to test the pre- and post-conditions themselves, and are definitely happy-path focused. But such tests may be sufficient to test the happy-path code itself (which the in-code checks are also testing). It would be ridiculous to have an entire test suite with no assertions for these reasons, but it's not ridiculous (in isolation) to see some unit tests with no assertions. In theory -- and this is not advice: theory and practice are different -- but in theory, if you've absolutely air-tightly tested the "happy path", then you've basically proven no other paths occur (short of cosmic rays). But you could actually make this same argument about unit tests with assertions: do you have any test that those assertions are written correctly? Do you unit test your unit tests? Pre- and post-conditions living "in situ" are the equivalent thing to "control" and test assertions (respectively) living in your unit tests. Would you be more comfortable if the in-situ checks were simply cut/pasted into the unit test? I wouldn't be!

kcb 3y ago

That's why the dev teams tests and the QA teams tests are not mutually exclusive.

ponector 3y ago
Testing is continuous multilayered multistaged process. Testing should start before first developer wrote first line of code for the project. Architecture blueprints, set of requirements should be tested as early as possible. But that is not happening in real life, only in books. In real life pm will bring cheap contractor from India one month before the target release date.

feoren 3y ago

> I've seen developers writing tests with no assertions This can be OK if the code executing without throwing exceptions is itself testing something. If you have a lot of assertions written directly into the code, as pre- or post-conditions for instance. But I'm guessing that wasn't the case here.

WrongAssumption 3y ago
Why would it be ok to not test the assertions would be triggered if the conditions are bad? How would you verify that the assertions are correct with just a happy path? If you run a code with pre-post assertions, then remove all the assertions the same test will continue to pass.
- feoren 3y ago
  Agreed: such tests are not sufficient to test the pre- and post-conditions themselves, and are definitely happy-path focused. But such tests may be sufficient to test the happy-path code itself (which the in-code checks are also testing). It would be ridiculous to have an entire test suite with no assertions for these reasons, but it's not ridiculous (in isolation) to see some unit tests with no assertions. In theory -- and this is not advice: theory and practice are different -- but in theory, if you've absolutely air-tightly tested the "happy path", then you've basically proven no other paths occur (short of cosmic rays). But you could actually make this same argument about unit tests with assertions: do you have any test that those assertions are written correctly? Do you unit test your unit tests? Pre- and post-conditions living "in situ" are the equivalent thing to "control" and test assertions (respectively) living in your unit tests. Would you be more comfortable if the in-situ checks were simply cut/pasted into the unit test? I wouldn't be!