mirror of
git://source.winehq.org/git/wine.git
synced 2024-10-31 11:43:31 +00:00
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:
parent
2a54aac7c5
commit
9553e9bda2
1 changed files with 35 additions and 22 deletions
|
@ -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:\></>cd dlls\kernel\tests\Output\Win32_MSVC_Headers
|
||||
<prompt>C:\dlls\kernel\tests\Output\Win32_MSVC_Headers></>kernel32_test path
|
||||
<prompt>C:\wine\dlls\kernel\tests\Output\Win32_MSVC_Headers></> 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,&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,&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>
|
||||
|
||||
|
|
Loading…
Reference in a new issue