Add trailing '\n's to ok() and trace() calls.

Point to the pre-compiled winetest binaries.
A couple of small tweaks here and there.
This commit is contained in:
Francois Gouget 2004-09-07 20:42:41 +00:00 committed by Alexandre Julliard
parent 2a54aac7c5
commit 9553e9bda2

View file

@ -65,7 +65,7 @@
When a test fails, one immediately knows what was the expected
behavior and which APIs are involved. Thus regressions caught
this way should be detected earlier, because it is easy to run
all tests on a regular basis, and easier to fix because of the
all tests on a regular basis, and be easier to fix because of the
reduced diagnosis work.
</para>
</listitem>
@ -118,7 +118,8 @@
set its contents, possibly check length restrictions, and verify the
results using WM_GETTEXT. Similarly one could create a listbox and
check the effect of LB_DELETESTRING on the list's number of items,
selected items list, highlighted item, etc.
selected items list, highlighted item, etc. For concrete examples,
see <filename>dlls/user/tests/win.c</> and the related tests.
</para>
<para>
However, undocumented behavior should not be tested for unless there
@ -167,11 +168,12 @@
following:
<screen>
<prompt>$ </>../../../tools/runtest -q -M kernel32.dll -p kernel32_test.exe.so thread.c
<prompt>$ </>../../../tools/runtest -p kernel32_test.exe.so thread.c
<prompt>$ </>../../../tools/runtest -P wine -p kernel32_test.exe.so thread.c
thread.c: 86 tests executed, 5 marked as todo, 0 failures.
</screen>
The '-P wine' options defines the platform that is currently being
tested. Remove the '-q' option if you want the testing framework
The '-P wine' option defines the platform that is currently being
tested and is used in conjunction with the 'todo' statements (see
below). Remove the '-q' option if you want the testing framework
to report statistics about the number of successful and failed tests.
Run <command>runtest -h</> for more details.
</para>
@ -189,8 +191,15 @@ thread.c: 86 tests executed, 5 marked as todo, 0 failures.
<sect3>
<title>Debian GNU/Linux</title>
<para>
On Debian all you need to do is type <command>apt-get install
mingw32</>.
On Debian do <command>apt-get install mingw32</>.
</para>
<para>
The standard MinGW libraries will probably be incomplete, causing
'undefined symbol' errors. So get the latest
<ulink url="http://mirzam.it.vu.nl/mingw/">mingw-w32api RPM</>
and use <command>alien</> to either convert it to a .tar.gz file
from which to extract just the relevant files, or to convert it
to a Debian package that you will install.
</para>
</sect3>
<sect3>
@ -241,11 +250,15 @@ thread.c: 86 tests executed, 5 marked as todo, 0 failures.
<sect2>
<title>Using pre-compiled binaries</title>
<para>
Unfortunately there are no pre-compiled binaries yet. However if
send an email to the Wine development list you can probably get
someone to send them to you, and maybe motivate some kind soul to
put in place a mechanism for publishing such binaries on a regular
basis.
The simplest solution is to download the
<ulink url="http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe">latest
version of winetest</>. This executable contains all the Wine
conformance tests, runs them and reports the results.
</para>
<para>
You can also get the older versions from
<ulink url="http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/">Paul
Millar's website</>.
</para>
</sect2>
<sect2>
@ -322,7 +335,7 @@ thread.c: 86 tests executed, 5 marked as todo, 0 failures.
method. So to run the kernel 'path' tests you would do:
<screen>
<prompt>C:\&gt;</>cd dlls\kernel\tests\Output\Win32_MSVC_Headers
<prompt>C:\dlls\kernel\tests\Output\Win32_MSVC_Headers&gt;</>kernel32_test path
<prompt>C:\wine\dlls\kernel\tests\Output\Win32_MSVC_Headers&gt;</> kernel32_test path
</screen>
</para></listitem>
</itemizedlist>
@ -386,8 +399,8 @@ START_TEST(paths)
You can use <function>trace</> to print informational messages. Note
that these messages will only be printed if 'runtest -v' is being used.
<screen>
trace("testing GlobalAddAtomA");
trace("foo=%d",foo);
trace("testing GlobalAddAtomA\n");
trace("foo=%d\n",foo);
</screen>
</para>
<para>
@ -395,8 +408,8 @@ START_TEST(paths)
they behaved as expected:
<screen>
ATOM atom = GlobalAddAtomA( "foobar" );
ok( GlobalFindAtomA( "foobar" ) == atom, "could not find atom foobar" );
ok( GlobalFindAtomA( "FOOBAR" ) == atom, "could not find atom FOOBAR" );
ok( GlobalFindAtomA( "foobar" ) == atom, "could not find atom foobar\n" );
ok( GlobalFindAtomA( "FOOBAR" ) == atom, "could not find atom FOOBAR\n" );
</screen>
The first parameter of <function>ok</> is an expression which must
evaluate to true if the test was successful. The next parameter is a
@ -431,7 +444,7 @@ START_TEST(paths)
of a bad error message:
<screen>
ok(GetThreadPriorityBoost(curthread,&amp;disabled)!=0,
"GetThreadPriorityBoost Failed");
"GetThreadPriorityBoost Failed\n");
</screen>
This will yield:
<screen>
@ -451,7 +464,7 @@ thread.c:123: Test failed: GetThreadPriorityBoost Failed
BOOL rc;
...
rc=GetThreadPriorityBoost(curthread,&amp;disabled);
ok(rc!=0 && disabled==0,"rc=%d error=%ld disabled=%d",
ok(rc!=0 && disabled==0,"rc=%d error=%ld disabled=%d\n",
rc,GetLastError(),disabled);
</screen>
This will yield:
@ -485,7 +498,7 @@ thread.c:123: Test failed: rc=0 error=120 disabled=0
for some tests you may want to define a macro such as the following:
<screen>
#define eq(received, expected, label, type) \
ok((received) == (expected), "%s: got " type " instead of " type, (label),(received),(expected))
ok((received) == (expected), "%s: got " type " instead of " type "\n", (label),(received),(expected))
...
@ -512,7 +525,7 @@ thread.c:123: Test failed: rc=0 error=120 disabled=0
<screen>
todo_wine {
SetLastError( 0xdeadbeef );
ok( GlobalAddAtomA(0) == 0 && GetLastError() == 0xdeadbeef, "failed to add atom 0" );
ok( GlobalAddAtomA(0) == 0 && GetLastError() == 0xdeadbeef, "failed to add atom 0\n" );
}
</screen>
On Windows the above check would be performed normally, but on Wine it
@ -567,7 +580,7 @@ ok ( GetLastError() == WIN9X_ERROR || GetLastError() == NT_ERROR, ...);
<!-- FIXME: Strategies for testing threads, testing network stuff,
file handling, eq macro... -->
file handling... -->
</chapter>