[Scons-users] best practices: unit tests

[Rob Boehne]

R030t1,

You're argument that unit tests are not perfect is quite valid.  I personally find them indispensable, I'd sooner find a new employer than be responsible for code that I'm not allowed to develop with TDD.   However that's really off-topic for this list, and doesn't address Mats' question of "how" to do it well.

Mats:

Having the unit tests part of the Scons tree is the best way to do this.   Because giving a unit test target should rebuild the product being tested when necessary, otherwise you could test out of date products.  Using Scons to build tests, run tests and generate reports is easier because you can reuse environments, and I keeps track of what is current.
I say this mainly because we have a product that builds the tests with Scons, and then has a separate python script to run the tests.  When we decided to run the tests in parallel, we had to implement this ourselves, whereas Scons would have already been doing that.  My advice would be to think of a tree where the ultimate output is a report of the test run, output from each test are dependencies, and so on.

HTH,

Rob Boehne

On 2/1/18, 9:33 PM, "Scons-users on behalf of R0b0t1" <scons-users-bounces at scons.org on behalf of r030t1 at gmail.com> wrote:

    On Thu, Feb 1, 2018 at 8:19 PM, Mats Wichmann <mats at wichmann.us> wrote:
    > On 02/01/2018 04:11 PM, R0b0t1 wrote:
    >
    >> Unit tests are a mixed bag.
    >
    > Yeah, I know nearly all the arguments. Made a lot of them myself :)  But
    > that's how modern projects work: the founders lay down TDD-style "thou
    > shalt not write an API without unit tests" rules.  It's not my call to
    > change those requirements, and I think they're actually fine: API tests
    > work on verifying documented behavior and don't have the same
    > variability problems you cite.
    >
    
    But they don't. API tests verify that the input selected gives the
    output in the test. It is not a description that holds for all valid
    input.
    
    There is an even larger problem, which is that even if you can prove
    that a program is "type safe" all you have done is prove that it is
    logically consistent within some theoretical framework. Even if you
    can prove it adheres to a specification, you still haven't proved that
    the specification reflects what you actually want to happen.
    
    >> It sounds like referring you to an existing system would help - so,
    >> you might look at Ant and Maven and the structure of large Java
    >> projects.
    >
    > Sure, you can depend on external stuff.  The project I'm on does (in
    > particular, the java additions do make use of Maven, but I don't touch
    > those bits, so...).  The question was about doing this in scons, since
    > this is an scons list. If the best practice is: don't try to do it in
    > scons, that's fine, I was just trying to flush out opinions.
    >
    
    Sorry, I wasn't suggesting you rely on Ant/Maven. But for e.g. Python
    you just use the unittest module, or Nose and py.test and then run it.
    With Java projects, the tests/ directory is usually just complete
    programs that run. It may be one program. It doesn't matter which
    build system you are using.
    
    The answer is very language specific.
    
    Cheers,
         R0b0t1
    _______________________________________________
    Scons-users mailing list
    Scons-users at scons.org
    https://pairlist4.pair.net/mailman/listinfo/scons-users