Alexandre Julliard wrote:
Andriy Palamarchuk apa3a@yahoo.com writes:
Can you suggest how to implement these switches - as command-line arguments or environment variables?
Environment variables are better. I did that already
in the perl
framework, look at the runtest script for the
variables I'm using. You
probably want to do things the same way so that it's
easier to mix
Perl and C tests.
Looked at the runtest script. Defined processing of environment variables WINETEST_DEBUG and WINETEST_DIE_ON_FAILURE.
As we discussed before we can define platform at runtime, so do we really need the WINETEST_PLATFORM switch? This is one more thing to break. Somebody will eventually mess with the switch when they run the test application manually. Automatic platform definition is pretty reliable.
Attached new version of the library.
I don't have a die on failure flag though, but I don't think this is really necessary.
It is not really necessary, only nice thing to have :-)
I was thinking about situations when we need to run big batch of tests on unfamiliar platform - e.g. on untested version of Windows or move tests between Win32 implementation. In these situations we are interested to see all possible failures to see amount of work needed to fix them.
On other hand we'd like to see only 1 failure on testing regressions.
I'm going to leave the option for now.
Andriy Palamarchuk
__________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
Andriy Palamarchuk apa3a@yahoo.com writes:
As we discussed before we can define platform at runtime, so do we really need the WINETEST_PLATFORM switch? This is one more thing to break. Somebody will eventually mess with the switch when they run the test application manually.
Well, that's the point, so that you can change the platform to see what happens. I needed that to test my todo implementation without having to reboot under Windows.
Automatic platform definition is pretty reliable.
I don't think checking for a Wine registry key is reliable at all. Nothing prevents someone from having this key under Windows.
--- Alexandre Julliard julliard@winehq.com wrote:
Andriy Palamarchuk apa3a@yahoo.com writes:
As we discussed before we can define platform at runtime, so do we really need the
WINETEST_PLATFORM
switch? This is one more thing to break. Somebody
will
eventually mess with the switch when they run the
test
application manually.
Well, that's the point, so that you can change the platform to see what happens. I needed that to test my todo implementation without having to reboot under Windows.
Do you mean testing of TODO functionality for Perl winetest framework or running tests, marked as TODO?
1 - sure, you can test this with environment variable, but I'd expect this variable to be used for debugging only. I wonder why you are against using automatic recognition in production tests.
2 - TODO tests are executed in the same way as usual tests, only their results are reported differently
Automatic platform definition is pretty reliable.
I don't think checking for a Wine registry key is reliable at all. Nothing prevents someone from having this key under Windows.
More reliable than environment variable anyway. Nothing prevents someone from forgetting to set correct value to the environment variable before running test application :-)
In either case the person will learn his mistake very quickly, after all those WINE_TODOs will blow up in his fase.
Andriy Palamarchuk
__________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
Andriy Palamarchuk apa3a@yahoo.com writes:
More reliable than environment variable anyway. Nothing prevents someone from forgetting to set correct value to the environment variable before running test application :-)
This will be taken care of by the test environment. You don't need to set the variable when running make test, but you have the possibility to set it if you want to override the default for whatever reason. I don't see why we should impose a less flexible solution that won't be more robust anyway.
-
Alexandre Julliard -
Andriy Palamarchuk