[Scons-users] Build and run unit tests automatically on target build

[Gary Granger]

What if you use the library file itself to insert the testing stage in 
front of the external dependencies?  Something like:

lib_under_test = env.Library(...)
lib_tested = env.Dir("#/tested/lib/").File(lib_under_test.name)
test_program = env.Program("test_program", LIBS=[lib_under_test])
env.Command(lib_tested, test_program,
     actions=["$SOURCE <test arguments>",
                      Copy(lib_tested, lib_under_test)])

And of course you could turn this into a pseudo-builder, or into an 
actual builder which generates the actions to copy the tested library 
and return that node as the target.

This is the rough idea and untested, but it makes sense to me to first 
"stage" the library in a different location or name, then move it to a 
"production" location or name if the tests pass.  Everything else uses 
lib_tested as the dependency, so SCons can follow the dependencies and 
run the test any time the library is rebuilt.

On 6/17/24 14:18, Mats Wichmann wrote:
> On 6/17/24 13:26, Matthew Ryan wrote:
>> I've been looking for some way of building and running a unit test
>> after another target is run, but so far have been unable to come up
>> with a recipe.
>>
>> The specific example is that of a C/C++ static library built by
>> `env.Library()` - I want a setup where, whenever the static library is
>> rebuilt, a unit test (built by `env.Program` and linked against the
>> static library) is built and run automatically, and if it fails, the
>> build fails, so anything later on that links against libfoo would not
>> build.
>>
>> Is such a thing possible?
>
> A number of approaches have been tried over the years. It's not 
> "native" to scons, which likes to deal in a dependency tree and figure 
> out what's out of date and build that. if running a unit test produces 
> a predictably-named output file you can wire up the plumbing so that 
> file looks like a target, then it becomes more natural.
>
> There's a wiki entry which isn't really that great:
>
> https://github.com/SCons/scons/wiki/UnitTests
>
> There was someone who wrote a blog post about it doing something a bit 
> better - there are a couple of links in the wiki page.
>
> Someone wrote up a github project for a cxxtest tool (whch doesn't 
> help if cxxtest doesn't work for you, but the ideas might).
>
> https://github.com/ptomulik/scons-tool-cxxtest
>
> When I first started using SCons it was on a C++ project that did 
> triggered unit testing (including some extras, like "if on Linux, also 
> run valgrind on the binary"), I tried to fix the mechanism but as I 
> was very new to SCons at the time I never came up with something I 
> thought was better.  I can post excerpts of that approach if wanted, 
> would take a little memory refresh as it's been about seven years.  In 
> my aside from the first paragraph, the log produced by valgrind became 
> a target, so that part was actually pretty solid.
>
> This is just a quick response, feel free to ask more questions and 
> give more details on what didn't work, etc.
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users