[testing] Reorganize the test structure. #1243
Conversation
schweitzpgi
requested review from
bettinaheim,
amccaskey and
bmhowe23
as code owners
|
What is the desired convention for when items would go into |
|
It would be great to put your PR description on a README for future reference. |
Basically, don't put a test that is expected to execute itself anywhere in I was thinking of renaming the |
|
FWIW: With this change, the regression tests run quickly and do not freeze or crush a smaller/weaker/malnourished system. |
schweitzpgi
force-pushed
the
ch-rearrange.tests
branch
from
c4ac946
to
61bfac9
Compare
Added |
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
The various directories should be organized as follows: test - these are small regression tests that can be run very quickly and test small combinations of functionality to prevent regressions. does not use gtest framework, but rather FileCheck and friends. unittests - similar to test, but fixating on one particular "unit". tests the unit's boundaries, limits, etc. to make sure that a particular encapsulated blob of computation (the unit) works as advertised. uses gtest framework. targettests - not like the 2 above. these are end-to-end tests that might take a long time to run but test a whole 9 yards of functionality. so if you wanted to run a game of quantum nethack, it would go here. note: eventually these tests should be executable out-of-tree so that installations of cuda quantum can be tested sans source code. python/tests - these should be folded into the above testing infrastructure.
schweitzpgi
force-pushed
the
ch-rearrange.tests
branch
from
61bfac9
to
ab7b210
Compare
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
The various directories should be organized as follows:
test - these are small regression tests that can be run very quickly and test small combinations of functionality to prevent regressions. does not use gtest framework, but rather FileCheck and friends.
unittests - similar to test, but fixating on one particular "unit". tests the unit's boundaries, limits, etc. to make sure that a particular encapsulated blob of computation (the unit) works as advertised. uses gtest framework.
targettests - not like the 2 above. these are end-to-end tests that might take a long time to run but test a whole 9 yards of functionality. so if you wanted to run a game of quantum nethack, it would go here. note: eventually these tests should be executable out-of-tree so that installations of cuda quantum can be tested sans source code.
python/tests - these should be folded into the above testing infrastructure.