Hi,
In AmberTools/test/Makefile
in the case where fast testing is intentionally
not performed for program bla a clarifying comment was added
to target fast.bla. This all should be crystal clear upon
glancing at that Makefile.
And in general take a look at AmberTools/test/antechamber/Makefile
or AmberTools/test/leap/Makefile to see the simple target structure.
(When the testing scaffolding is a Makefile hierarchy
then adding fast just means adding a fast target and rearranging
the existing individual test targets.)
I've made the fast targets for leap following your advice to
elide glycam, thanks.
So far fast takes just under 12 seconds on a slow 5.5 year old machine.
I have ideas on how to shave a second or 2 off that.
Please add or send your test selections for the fast suite.
scott
On Fri, Sep 08, 2017 at 12:28:58PM +0000, B. Lachele Foley wrote:
> If there are no fast-tests to add in a domain, do you want us to:
>
> * explicitly remove them from the main fast-tests makefile?
> * make a sub-makefile that just returns?
>
> Does it matter?
>
> Example: I think we can leave out the glycam tests entirely from the fast set. If leap works in general, that should be enough. Keep the glycam tests only for the detailed runs.
>
> A related radical thought:
>
> For a really fast, very minimal set of tests, just make sure that each executable prints a usage statement (or hello-world or expected error message, etc.).
>
>
> From: Scott Brozell <sbrozell.rci.rutgers.edu>
>
> I have started work on a fast test suite and am looking for
> volunteers to select apt tests:
>
> cd AmberTools/test
> make fast.serial
>
> Here are the logs:
>
> AmberTools/test/Makefile | 33 +++++++++++++++++++++++++++++++++
> First stab at a fast test suite: my brilliant approach is s/test/fast/g
> So fast.serial is the target for running the serial fast test suite;
> fast.bla is the target name for the reduced set of tests for program bla;
> the hard work is of course repartitioning tests into fast ones and not
> fast ones :-O I have started that for only antechamber.
>
> AmberTools/test/antechamber/Makefile | 12 +++++++-----
> First stab at a fast test suite: my brilliant approach is s/test/fast/g
> So fast is the target name for the reduced set of tests for antechamber.
> I have moved some fast and otherwise worthy tests into the fast target,
> but have not thoroughly examined functionality coverage.
>
> thanks,
> scott
>
> On Wed, Sep 06, 2017 at 09:00:52AM -0400, David A Case wrote:
> >
> > It's clear that people are generally not running tests before making
> > commits to master. Part of that is bad habits, but a big part is probably
> > that it takes forever to run the full test suite.
> >
> > So, I'm looking for a volunteer to create a "fast/short" test suite: i.e.
> > a target in $AMBERHOME/test/Makefile that would cover the basics and could
> > complete in a few minutes. Some discretion is needed, but such a thing
> > would clearly skip the mmpbsa/FEW tests, only do a few of the hundreds
> > of qmmm tests, etc. This could skip problematic tests as well, so the
> > expectation would be that everything in the "fast/short" suite would PASS.
> >
> > Then we could really lean on people who make commits to master that break
> > things, and automated nightly tests could (often) use just the shorter
> > version.
> >
> > I don't think it is really necessary to do this for pmemd, since those
> > tests run reasonably quickly as is. But I'm open to counterarguments there.
> >
> > Post a note on amber-developers if you decide to take this on, so we don't get
> > duplicate efforts.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Sep 08 2017 - 10:00:02 PDT
