Closed nicmcd closed 4 years ago
To be honest I haven't run into any problems. The build time is pretty fast (and probably won't get much faster by splitting up the test binary), and you can use --test_filter if you only want to run one the tests in one file during development
Each time I make a change I re-run the unit tests to make sure nothing was broken. The problem is that all tests have to re-run, and they run serially. There are two benefits to multiple binaries:
bazel test :*
will only run tests that need to be run and will use the cached results for the others.bazel test :*
will utilize all the cores on the machine running the tests which is a plentiful speed up of 8x-64x on typical workstations. Currently the serial time is 35+ seconds. There is the gtest-parallel project that I've used in the past. Maybe that is the best of both worlds here.
How about something like this in the BUILD file?
[
cc_test(
name = test_src.replace(".cc", ""),
srcs = [test_src],
deps = [":lib"],
)
for test_src in glob("src/**/*_TEST.cc")
]
I'm not too sure what the test name should be.
The one problem with that is that the test code depends on test libraries, so the source files aren't completely independent. Take a look at src/allocator/Allocator_TEST.h
If there's only a few very general things like TestSetup_TEST.h, how about a separate "test_lib" dependency?
There aren't very many but they aren't all in the same location (e.g., test/). My preference is that new code files should be added without BUILD file changes. Ideally gtest would just have a --parallel flag. If I can't get that, I think gtest-parallel is the way to go.
bazel test :*
will run all unit tests in parallel now with everything else. bazel test :unit_tests
will run only the unit tests.
SuperSim currently has one big unit test binary. To speed up testing it would be nice to have many test binaries, likely one per test source file. SuperSim uses a single BUILD file for the entire repository. This is made easy via naming conventions. To create many unit test binaries, the BUILD would grow significantly and the addition of new test files would require changes to the BUILD file, which is not a current requirement. @knrafto, know of any ways to handle this nicely?