newlib/winsup/testsuite
Corinna Vinschen 45d061cccf * winsup.api/mmaptest01.c: New test. 2001-04-03 08:39:21 +00:00
..
config * config/default.exp: Remove unneeded debugging output. 2001-03-09 15:39:28 +00:00
libltp Add 'const' qualifiers where needed to avoid compiler warnings. 2000-09-06 14:21:53 +00:00
winsup.api * winsup.api/mmaptest01.c: New test. 2001-04-03 08:39:21 +00:00
ChangeLog * winsup.api/mmaptest01.c: New test. 2001-04-03 08:39:21 +00:00
Makefile.in * config/default.exp: Remove unneeded debugging output. 2001-03-09 15:39:28 +00:00
README import winsup-2000-02-17 snapshot 2000-02-17 19:38:33 +00:00
configure Importing Egor's testsuite. 2000-09-03 03:58:18 +00:00
configure.in Importing Egor's testsuite. 2000-09-03 03:58:18 +00:00

README

1999-12-23  DJ Delorie  <dj@cygnus.com>

Here are some notes about adding and using this testsuite.

First, all the programs are linked with new-libcygwin.a, which is just
like libcygwin.a, except that it wants new-cygwin1.dll, not
cygwin1.dll.  The testsuite adds the winsup build directory to the
PATH so that new-cygwin1.dll can be found by windows during testing.

Because we'll probably run into complaints about using two DLLs, we
run cygrun.exe for each test.  All this does is run the test with
CreateProcess() so that we don't attempt to do the special code for
when a cygwin program calls another cygwin program, as this might be a
"multiple cygwins" problem.

Any test that needs to test command line args or redirection needs to
run such a child program itself, as the testsuite will not do any
arguments or redirection for it.  Same for fork, signals, etc.

The testsuite/winsup.api subdirectory is for testing the API to
cygwin1.dll ONLY.  Create other subdirs under testsuite/ for other
classes of testing.

Tests in winsup.api/*.c or winsup.api/*/*.c (only one subdirectory
level is allowed) either compile, run, and exit(0) or they fail.
Either abort or exit with a non-zero code to indicate failure.  Don't
print anything to the screen if you can avoid it (except for failure
reasons, of course).  One .c file per test, no compile options are
allowed (we're testing the api, not the compiler).

Tests whose filename begin with "xf-" will be *expected* to fail, and
will "fail" if they compile, run, and return zero.  Note that the
*only* purpose for adding this feature is to test the testing
framework itself.  All real tests should NOT be named xf-*, and should
pass for real (compile, run, return 0) if the dll is working
correctly.  Do not use xf-* to "silence" a failure that you know isn't
going to get fixed for a while; let it just keep failing.  There are
five "sample" tests that demonstrate how the framework works and what
happens to each condition.

"make check" will only work if you run it *on* an NT machine.
Cross-checking is not supported.