Testing edge cases and undocumented behavior

Vincent Povirk madewokherd at gmail.com
Thu Aug 25 21:01:09 CDT 2011

A test that passes on Windows and fails on Wine is not sufficient to
motivate a change to Wine.

I think we normally consider the following factors:
* Is the change correct? If not, we should consider leaving Wine
alone, but I can imagine there being other compelling reasons, in rare
circumstances, to knowingly make Wine less like Windows.
* Is a Windows application likely to need this? If we already know of
such an application, that's a strong indicator that we should make the
change, but even then it's not automatic.
* Would a Windows application that relies on this behavior be
considered "broken"? Is it possible that newer versions of Windows,
different Windows versions, or phases of the moon could cause this
application to break? Is such an application relying on implementation
details that it (and we) shouldn't care about? If so, the actual
presence of an application that relies on the windows behavior is not
so important.
* Does this make the code simpler or more complex? If it makes the
code simpler and more correct at the same time (without breaking
anything), we should do it regardless of whether we know of an
application that needs it. But complexity has a cost in maintenance,
so we need some positive justification before we do something that
makes the code more complex (though not necessarily a specific
* Will this change become more difficult to make if we continue to
develop Wine without it? If it will, and there's a reasonable chance
we'll need it, I will try to fix it before doing any further
development that would make it more difficult for me.
* Is the change likely to break something else? I've seen regressions
caused by parts of Wine that use other parts of Wine incorrectly but
happen to work because Wine is broken in two ways (until one of them
is fixed). We can't always anticipate them, but when we can, we should
try to fix things in an order that doesn't result in a regression.
* Can we do this correctly within the environment where Wine must
function? Sometimes Unix, X, or the other systems interact with make
it impossible for us to fix a bug, or cause problems if we do that are
worse than the bug we fix.

Like the fair use principles, none of this is an absolute rule. You
just have to look at each individual case. Usually, though, I think it
will be obvious which ones apply.

More information about the wine-devel mailing list