Discussion:
automatic running of regression tests which should have an assertion failure
(too old to reply)
James Kanze
2009-07-15 14:59:03 UTC
Permalink
I'm currently porting some library code to Windows (from Unix).
The library code is designed to fail (assertion failure) in case
of illegal input, and the test suite (written in Unix shell, and
executed under Windows using CygWin bash) actually tests
this---it expects the programs to fail, and the test fails if
they don't. The problem is that when the program fails, I get
one of these pop-up windows, stating that "testIncr.exe has
encountered a problem and needs to close", with an offer to
debug or to close. And the test suite hangs until I've clicked
on one of the buttons. Which means that it can't effectively be
used for regression tests.

So how can I inhibit this, so that the test program just returns
some incorrect error code, and the test suite continues?

--
James Kanze (GABI Software) email:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alex Blekhman
2009-07-15 16:37:46 UTC
Permalink
Post by James Kanze
So how can I inhibit this, so that the test program just returns
some incorrect error code, and the test suite continues?
If you can control source code of the test program, then you may
insert a call to SetErrorMode function at the beginning of the
`main'. It allows to silent various message boxes and return a
error code instead.

HTH
Alex
James Kanze
2009-07-21 16:34:14 UTC
Permalink
Post by Alex Blekhman
Post by James Kanze
So how can I inhibit this, so that the test program just
returns some incorrect error code, and the test suite
continues?
If you can control source code of the test program, then you
may insert a call to SetErrorMode function at the beginning of
the `main'. It allows to silent various message boxes and
return a error code instead.
Sorry for the delay, but I wanted to test it first. It did
sound like what I wanted, but I'm still getting the pop-up
boxed. I called:
SetErrorMode( SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX ) ;
, which seemed to be what I needed according to the
documentation.

The documentation also says that the minimum supported client is
Windows 2000 *Professional*. Does this mean that it won't work
on the Family versions? (My home machine runs Windows XP
Family.)

--
James Kanze (GABI Software) email:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alex Blekhman
2009-07-22 08:48:25 UTC
Permalink
Post by James Kanze
Sorry for the delay, but I wanted to test it first. It did
sound like what I wanted, but I'm still getting the pop-up
SetErrorMode( SEM_FAILCRITICALERRORS |
SEM_NOGPFAULTERRORBOX ) ;
, which seemed to be what I needed according to the
documentation.
This code works for me:

int foo(int x, int y)
{
return x / y;
}

int bar(int* p)
{
return *p;
}

int main()
{
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);

// use one of the following
foo(5, 0);
bar(NULL);

return 0;
}

Are you sure that no other thread in the process calls
SetErrorMode?
Post by James Kanze
The documentation also says that the minimum supported client is
Windows 2000 *Professional*. Does this mean that it won't work
on the Family versions? (My home machine runs Windows XP
Family.)
I think it is an error in the documentation. My offline SDK docs
say that supported client versions are: Windows Vista, Windows XP,
Windows 2000 Professional, Windows NT Workstation, Windows Me,
Windows 98, or Windows 95.

Alex
James Kanze
2009-07-24 13:42:41 UTC
Permalink
Post by James Kanze
Sorry for the delay, but I wanted to test it first. It did
sound like what I wanted, but I'm still getting the pop-up
SetErrorMode( SEM_FAILCRITICALERRORS |
SEM_NOGPFAULTERRORBOX ) ;
, which seemed to be what I needed according to the
documentation.
Yes. As usual, it's when I make the stupiest errors that I
shout the loudest. I put the call in my test framework, which
in this case, calls a separate process for each tests (since the
test case should cause the program to abort, if everything
works). Putting it in the actual program which aborts works
much better:-).

Everything's working now, thanks.

--
James Kanze (GABI Software) email:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loading...