On Tue, 23 Apr 2019, Kip Warner wrote:
Now suppose the TestStartDaemon.sh bails for some reason. There is no
point on doing all the queries and having them all fail. There has to
be a sane way of handling this scenario.
Having all the dependent tests fail seems ok, as long as the failure
is e
On Tue, 2019-04-23 at 10:25 -0500, Bob Friesenhahn wrote:
> On Mon, 22 Apr 2019, Kip Warner wrote:
> > How can I solve this problem?
>
> By using the TAP test framework you could organize your related
> tests into ordered scripts which assure that test
> construction/destruction is orderly even if
On Mon, 2019-04-22 at 22:33 -0600, John Calcote wrote:
> Try using a stamp file only created on success. To do this you’ll
> need to wrap your test calls in a script that creates the stamp file
> on success.
Hey John,
Wrapping the script in another wrapper is possible, but I'd prefer not
to do th
On Mon, 22 Apr 2019, Kip Warner wrote:
How can I solve this problem?
By using the TAP test framework you could organize your related tests
into ordered scripts which assure that test construction/destruction
is orderly even if some tests fail. This approach may lose
parallelism if there ar
On Mon, Apr 22, 2019 at 10:12 PM Kip Warner wrote:
> How can I solve this problem?
Try using a stamp file only created on success. To do this you’ll need to
wrap your test calls in a script that creates the stamp file on success.
John
>
Hey list,
I have a bunch of unit tests declared in check_PROGRAMS and
check_SCRIPTS. Some tests can only be run after others, while some
others can only be run before others.
I've managed to solve this problem pursuant to § 15.2.1 via partial
ordering constraints. This is done by declaring explic
