http://bugs.winehq.org/show_bug.cgi?id=21773
--- Comment #8 from Ian Goddard iang@austonley.org.uk 2010-02-26 11:54:05 --- (In reply to comment #6)
It's not clear what you are trying to do
I'm trying to do two things at the same time. One is to provide you with regression testing and the other is to provide myself with user acceptance testing.
I hope we can both agree that best practice in testing starts with setting up a testing environment (sandbox) separate from the production environment so that neither can interfere with the other.
The instructions on the website for running wintest-latest will simply pick up the current wine version in the user's $PATH so it seems to be implied that the user has already installed the latest wine into the production environment. In other words, install first, test later. I hope I don't have to labour the point of how far this fails to meet best practice. If you have to consider deprecating something, this is a prime candidate.
On first glance your suggestion of running ./wine in the source tree seems OK in that it doesn't involve installing before test. However there's nothing to guarantee either of us that test and live environments won't interfere.
From your point of view you don't know that I don't have $WINEwhatever
environment variables set. If I do then the tests my pick up something from my production environment, for instance a registry setting or a dll which may affect testing.
From my PoV I don't know, even if I don't have such environment variables set,
that your S/W won't make some default assumptions, pick up my production environment and disturb it in some way.
Clearly better practice would be to use a script which would set its own environment variables. Just as dotests does. Maybe you should consider not only reprecating it, to coin a word, but making it the norm.
Ian