[Scons-users] HOWTO model a test suite using SCons

Stefan Seefeld stefan at seefeld.name
Fri Jan 1 11:58:24 EST 2016


On 01.01.2016 11:39, Dirk Bächle wrote:
> Hi Stefan (und ein Frohes Neues Jahr zurück! ;) ),

Danke ! :-)

>
> On 31.12.2015 23:56, Stefan Seefeld wrote:
>> Hello,
>>
>> I'd like to drive a test suite run with SCons, and I wonder whether
>> there already is prior art for this.
>> In particular, I'd like to invoke the test suite as a single target,
>> such that all the tests contained in it are executed, and at the end a
>> summary (number of passed / failed tests, names of failed tests) is
>> printed. I'm not quite sure how to achieve this.
>
> there are a ton of testing frameworks out there already, so what makes
> you think that SCons is better than any of them?

I know (I'm maintaining and contributing to some of them), and I don't
think SCons is better. But for the simple needs I have I don't want to
bring in an external dependency, I merely want to adapt the existing
build system a bit.

> In particular, you have to regard that SCons triggers its actions
> based on file-based content changes. There is no notion of "build
> stages", like a "build stage" separate from a "test stage". I'm
> mentioning this because most users that try to run tests with SCons,
> expect a kind of serial processing where first all targets are
> build...and then all tests are executed afterwards. This makes sense
> of course because the logging would get messed up easily, especially
> when running things in parallel. You would see schedules like:
>
>   Building target1
>   Building target2
>   Testing target2
>   Building target3
>   Testing target1
>   Testing target3
>
> Are you sure this is what you want?

It isn't (which is one reason why I asked). There are surely ways to
express the dependency graph that make the test execution being
scheduled only once all other targets are built.

In fact, I'm a little surprised that SCons' dependency graph nodes have
to be files. Why is that ? Couldn't that be an abstract entity that
handles its notion of 'up-to-date' and 'remake' polymorphically ? I was
indeed a bit surprised reading the SCons User's Guide that all the
examples were based on target *files*, rather than something more generic.
Is there no way to define a target that doesn't involve touching or
generating a file ?

Thanks,
        Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...



More information about the Scons-users mailing list