You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several test categories that can pass a run while reporting to have zero assertions. This is mostly due to one of two issues: Either the test category still uses the legacy framework for writing tests (which didn't have a concept of assertions, only fail/pass), or because the tests are written in the form of
The atomic tests are an example of the former case, the address_space an example of the latter.
We should strive to have explicit assertions whenever possible, as this makes debugging failing tests much easier. A simple first step for the scenario above would be to change the condition to CHECK(evaluateLotsOfThings()). While this doesn't really help debugging, it at least indicates to the reader of a test report that something was checked for (otherwise the test may as well have returned on it's first line).
Without having checked each one in detail, this is a list of test categories that I suspect are in need of revisiting:
address_space
atomic
device_event
error
exception_handling
header
host_task
kernel_args
kernel_bundle (has_kernel_bundle_*, get_kernel_ids_* and get_kernel_bundle_* tests)
pointers
std_classes
vector_load_store
The text was updated successfully, but these errors were encountered:
There are several test categories that can pass a run while reporting to have zero assertions. This is mostly due to one of two issues: Either the test category still uses the legacy framework for writing tests (which didn't have a concept of assertions, only fail/pass), or because the tests are written in the form of
The atomic tests are an example of the former case, the address_space an example of the latter.
We should strive to have explicit assertions whenever possible, as this makes debugging failing tests much easier. A simple first step for the scenario above would be to change the condition to
CHECK(evaluateLotsOfThings())
. While this doesn't really help debugging, it at least indicates to the reader of a test report that something was checked for (otherwise the test may as well havereturn
ed on it's first line).Without having checked each one in detail, this is a list of test categories that I suspect are in need of revisiting:
The text was updated successfully, but these errors were encountered: