CmdConformanceTests

1. Introduction

Writing cmd tests is a bit different than writing standard wine tests.

The tests are not written in C, but directly in the form of batch files, which are processed by wine cmd, then compared line by line to an associated expected result file.

Currently, we do the equivalent of

cmd /c test_builtins.cmd == test_builtins.cmd.exp

2. Adding tests

Find the relevant test section (--- Testing foo ---), or create it if necessary.
Enter the code to be processed in the .cmd file, and the expected result in the associated .exp file.
You might have to use some special keywords.

3. Dealing with missing or extra lines

If a test outputs a different number of lines in Wine than on Windows the actual output will get out of sync with the expected file, causing all the tests that follow to fail. To avoid that the test environment treats all lines that start with '---' as resynchronization points. That is, if it encounters a line starting with '---' in the output, it will read lines from the expected file until it finds the matching '---' line, and vice versa.

For this reason all section and subsection headers should start with three dashes in order to cut short the cascade of failures when this unexpectedly happens.

Also if you know that Wine is buggy and outputs an extra line (for instance), you can have it output a '---' line right after that test and match it with '@todo_wine@---'. This will mark the forced resynchronization as expected and the tests that follow will not be impacted. For instance:

Command

Windows Output

Wine Output

Matched by

buggy_command

result

result

result

error message

@todo_wine@---

echo ---

---

---

echo next test

next test

next test

next test

4. Keywords Handling

Both the .cmd and .exp files can contain some keywords, that are expanded or treated specially at runtime.

Only @space@ and @tab@ are usable in .cmd files.

4.1. Whitespace Characters

These keywords can be used in both the .cmd and .exp files:

Keyword  

substituted by

Comments

@space@

space character (' '

Should only be used for trailing spaces, where they can be difficult to spot

@tab@

tab character ('\t')

Should always be used instead of regular tab characters, for improved visibility

4.2. Environment

The following keywords are relevant to the test environment in general:

Keyword

substituted by

Example

@drive@

initial drive letter

C:

@pwd@

initial working directory

C:\Documents and Settings\wine\

@path@

initial path

\Documents and Settings\wine\

@shortpath@ 

initial path with short names 

\DOCUME~1\wine\

4.3. Test Helpers

The following keywords are not really substituted, but act as markers/indicators

Keyword

Usage

@todo_wine@  

Used at the start of an expected line to indicate a current failure on wine, so the test suite can run successfully.
To be removed when the test eventually succeeds.

@or_broken@  

Used to specify alternate/broken values returned by different windows versions (e.g. when a specific feature isn't available, etc.)
Test runner ignores the remainder of the line following the first @or_broken@ (keyword included).

Can be specified multiple times.

See the testing section of the Wine Developer's Guide for more information

4.4. Usage Example

@todo_wine@expected val@space@@or_broken@foo @tab@bar@or_broken@baz

specifies

  • a failure on wine (@todo_wine@)
  • normal value is 'expected val '
  • other windows versions can return 'foo \tbar'
  • still other windows versions can return 'baz'

5. Remarks / Tips & Tricks

5.1. Error Messages

Don't try to match error messages: they are language/locale specific and won't work on all (multilingual) windows versions.

Ex: don't use

echo foo_expr   -> foo_val@or_broken@Echo is OFF

but use

echo 'foo_expr' -> 'foo_val'@or_broken@''

instead

5.2. Temporary Files

If you need temporary batch/data files, don't add them to git, but create them at runtime, e.g. using echo foo>>tmpFile, and delete them afterwards.

The best way is generally to use names like foo, bar or baz, or even better a mkdir foobar & cd foobar at the start and cd .. & rd /s/q foobar at the end of your test section, if appropriate.

5.3. Processed File

The result file (processed .cmd file) and error file are deleted after usage. If you want to check their contents (e.g. for debugging tests), you can temporarily comment/delete the lines

DeleteFileA("test.out");
DeleteFileA("test.err");

in programs/cmd/tests/batch.c


CategoryQualityAssurance

CmdConformanceTests (last edited 2011-12-02 12:58:54 by FrancoisGouget)