[PATCH 2/5] wait until all data from earlier test has been written in test_waittxempty

Wolfgang Walter wine at stwm.de
Thu Sep 5 10:12:58 CDT 2013


Am Donnerstag, 5. September 2013, 23:58:57 schrieb Dmitry Timoshkov:
> Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
> > > The tests must pass under Wine without any additional "fixes" as they do
> > > currently under Windows. If you add some code to the tests which
> > > suddenly
> > > makes them pass under Wine - that's not a fix, Wine implementation
> > > should
> > > be fixed instead.
> > 
> > What I understood from Wolfgang's previous explanations is that there is
> > currently this situation:
> > 
> > todo_wine
> > 
> >  test1();
> > 
> > /* test1 fails because wine has a bug. As a side-effect, bytes will be
> > left in the transmission buffer under wine, but not under windows. */
> > test2();
> > /* test2 also fails under wine because of the failure of test1 that
> > influences the behaviour of test2, not because the functionality tested
> > by test2 is broken. This make it impossible to individually evaluate
> > test1() and test2(). */
> > 
> > So either
> > * you add code in between that resets the state so that test2 can be run
> > independently of whether test1 failed (as Wolfgang proposes), or * you
> > put the tests in completely different executables so they don't influence
> > each other (hopefully), or * you reorder the test so that first all the
> > tests that currently work under wine are run (under the assumption that
> > no regression will ever creep in), or * you require that bugs in wine
> > routines are fixed in the order that they are called in that test (which
> > would be strange)
> How about a patch set which does:
> 1/2. add a workaround to the tests to pass under Wine
> 2/2. fix Wine code and simultaneously remove the workaround added by 1/2.

I don't have a fix for

	WaitCommEvent() does not return ERROR_INVALID_PARAMETER without ovl 
structure

And I had no plans to do so nor did I claim.

I removed the side effect that this test makes the next test fail which tests 
the EV_TXEMPTY handling even if that it would work perfectly.

So:

test A
test B

test A fails on wine and this influences test B in such a way that it will 
always fail, too.

I remove this dependency.

Now test B succeeds. This is not because I worked arround a wine-bug in what B 
should test but because wine behaves correctly in this test.

And test A still fails.

> 
> But that looks even more strange if the fix contained in 2/2 could be
> sent alone.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Abteilungsleiter IT
Leopoldstraße 15
80802 München



More information about the wine-devel mailing list