The Windows API follows no standard, it is itself a de facto standard,
and deviations from that standard, even small ones, often cause
applications to crash or misbehave in some way.

The question becomes, "How do we ensure compliance with that standard?".
The answer is, "By using the API documentation available to us and
backing that up with conformance tests." Furthermore, a conformance
test suite is the most accurate (if not necessarily the most complete)
form of API documentation and can be used to supplement the Windows
API documentation.

Writing a conformance test suite for more than 10000 APIs is no small
undertaking. Fortunately it can prove very useful to the development
of Wine way before it is complete.

The conformance test suite must run on Windows. This is
necessary to provide a reasonable way to verify its accuracy.
Furthermore the tests must pass successfully on all Windows
platforms (tests not relevant to a given platform should be
skipped).

A consequence of this is that the test suite will provide a
great way to detect variations in the API between different
Windows versions. For instance, this can provide insights
into the differences between the, often undocumented, Win9x and
NT Windows families.

However, one must remember that the goal of Wine is to run
Windows applications on Linux, not to be a clone of any specific
Windows version. So such variations must only be tested for when
relevant to that goal.

Writing conformance tests is also an easy way to discover
bugs in Wine. Of course, before fixing the bugs discovered in
this way, one must first make sure that the new tests do pass
successfully on at least the Wine Test Bot base VMs.

Bugs discovered this way should also be easier to fix. Unlike
some mysterious application crashes, when a conformance test
fails, the expected behavior and APIs tested for are known thus
greatly simplifying the diagnosis.

To detect regressions. Simply running the test suite regularly
in Wine turns it into a great tool to detect regressions.
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 be easier to fix because of the
reduced diagnosis work.

Tests written in advance of the Wine development (possibly even
by non Wine developers) can also simplify the work of the
future implementer by making it easier for him to check the
correctness of his code.

Conformance tests will also come in handy when testing Wine on
new (or not as widely used) architectures such as FreeBSD,
Solaris x86 or even non-x86 systems. Even when the port does
not involve any significant change in the thread management,
exception handling or other low-level aspects of Wine, new
architectures can expose subtle bugs that can be hard to
diagnose when debugging regular (complex) applications.