[SERVER-70719] Create single-test unit test binaries for local development iteration Created: 19/Oct/22 Updated: 18/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jason Chan | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Correctness
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
When working on a single file it would be nice to iterate on just building that file rather than the whole file. Quoting jason.chan@mongodb.com Additionally, it’d be really nice to locally build a single test file. For example, I’d like to be able to generate an executable for producer_consumer_queue_test locally to minimize compile time when I’m working on that class. Today, we’d be able to do that but it’d involve defining a new CppUnitTest for every individual test file. I’m wondering if there’s something more clever that can be done with the CppUnitTest target to infer that a sub-target should be generated for each cpp file, and then keep it out of the evergreen build. |
| Comments |
| Comment by Alex Neben [ 20/Oct/22 ] | |||||||||
|
That is true in some cases and not others. In the cases where all the parts needed are in the single cpp file and included libraries and headers we should allow building this single target. It would be interesting to figure that out automatically but a simple solution is to provide the targets with the caveat that not all of them build. | |||||||||
| Comment by Andrew Morrow (Inactive) [ 20/Oct/22 ] | |||||||||
|
The problem with this is that you can't actually guarantee that a given single TU from a CppUnitTest can be meaningfully linked into an executable. For instance, if the unit test source file uses a helper class or fixture type that is implemented in another source file usually linked into the test program:
While it is possibly meaningful to make a standalone binary for the tests from bar_test.cpp by compiling just that file, it is probably impossible to do the same for foo_test.cpp since it needs symbols defined in foo_test_helpers.cpp. We would either need a way to annotate which files are/aren't buildable standalone (which is fragile and likely to become incorrect), or accept that requesting a single file unit test build may or may not work. I suppose we could also ban the above technique and require every C++ unit test TU to be standalone compilable, but we would need to show that the cost of having that restriction was outweighed by the advantages of having this single file build mode available to the developer population. Meanwhile, it is always possible to build any unit test binary on its own by building the target directly. Either by the filesystem path like [scons|ninja] ... build/install/bin/foo_test or the shorthand [scons|ninja] ... +foo_test. Once you have done this once, if you are iterating on foo_test.cpp then you still only pay to compile that one TU and link the binary. Linking just the one TU isn't likely to be that much faster than linking all the unit test TUs anyway, especially in --link-model=dynamic mode. And then on the execution side we already provide build rules to run just the tests from a given TU, so [scons|ninja] ... +foo_test.cpp will run just the tests from foo_test.cpp, after doing any necessary compilation and relinking. |