On Wed, Apr 24, 2002 at 03:58:36PM -0700, Francois Gouget wrote:
On Wed, 24 Apr 2002, Geoffrey Hausheer wrote:
[...]
Undocumented behavior should not be tested for unless an application
depends on that behavior. Our goal is not to make a clone of a specific
version of Windows but to be able
Paul Millar wrote:
dwMajorVersion dwMinorVersion dwPlatformID
Win3x+Win32s ?? VER_PLATFORM_WIN32s
Win95 40 VER_PLATFORM_WIN32_WINDOWS
Win98 410 VER_PLATFORM_WIN32_WINDOWS
On Wed, 24 Apr 2002, Geoffrey Hausheer wrote:
NT4.0 has a minor==0, so no, my test will not allow it to pass.
Yes, the dangers of sending emails when you're in a rush ...
However, I was not aware of how dwPlatformID was defined (and I miscounted
parentheses in your macro).
Its easy to
Paul Millar [EMAIL PROTECTED] writes:
Perhaps it would be best to make a test.h somewhere
and put all of these kind of definitions someplace so we don't need to
redefine them for each test.
Hmmm, was there an email about that a while ago? I thought Alexandre
wasn't happy with the
-Original Message-
From: Alexandre Julliard [EMAIL PROTECTED] {WineHQ-devel}
Version checks are a bad idea because this is not how Wine is
implemented. For instance GetLongPathName under Wine doesn't try to
fail if you are running with -winver win95, it just works. Adding
version
On Wed, 24 Apr 2002, Geoffrey Hausheer wrote:
[...]
One answer is not to test this, since it is not documented what the result
will be, but the OSes certainly behave differently, and it is possible that
some program takes advantage of this. I'm sure there are other similar
cases, and I'd like
but, MS's documentation:
http://msdn.microsoft.com/library/en-us/sysinfo/sysinfo_49iw.asp
suggests something more like:
#define WIN98_PLUS(version) \
( (version.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) \
( (version.dwMajorVersion 4) || \
(version.dwMajorVersion==4
Hi,
Found attached bug. Curiously, the test doesn't fail even if wine is
pretending to be Windows 95 :)
ChangeLog:
Fixed typo Major - Minor
BTW,
After the patch, the test for WIN98 or later is:
#define WIN98_PLUS(version) (version.dwMajorVersion==4 \
On 11 Apr 2002, Alexandre Julliard wrote:
I think it's much more useful to have line numbers, it makes it much
easier to find the offending test.
If they don't have a meaningful name, sure, but if the name is suitably
unique then grep -n, /, or Ctrl+S should work.
Most tests scripts will
On Wed, 10 Apr 2002, Francois Gouget wrote:
o If you set WINETEST_CONTINUE_ON_FAIL environment variable to 1, make
This looks like it is equivalent to make -k.
Oops, didn't know about that one :) I'll remove the
WINETEST_CONTINUE_ON_FAIL code ...
o The commands named_ok, set_name
On Thu, 11 Apr 2002, Paul Millar wrote:
[...]
-ok( ($atom = 0xc000) ($atom = 0x) !defined($wine::err) );
+named_ok( Adding atom \$name\ via GlobalAddAtomA(), ($atom =
0xc000) ($atom = 0x) !defined($wine::err) );
Here's the rationale: when a test result is displayed
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 11-Apr-02 Francois Gouget carved into stone:
On Thu, 11 Apr 2002, Paul Millar wrote:
[...]
-ok( ($atom = 0xc000) ($atom = 0x) !defined($wine::err) );
+named_ok( Adding atom \$name\ via GlobalAddAtomA(), ($atom =
0xc000)
Paul Millar [EMAIL PROTECTED] writes:
Here's the rationale: when a test result is displayed (currently only on
failure or success in a todo block) the file name and line number are
included. If the test file is altered then any tests after the edit will
have different line numbers. This
Hi,
The attached patch changes the way the regression testing works slightly.
The default behaviour should be the same, but there's some optional
enhancements:
o If you set WINETEST_REPORT_SUCCESS environment variable to 1,
successful tests are reported as well as unsuccessful ones.
o
-Original Message-
From: Paul Millar [EMAIL PROTECTED]
Subject: update to regression testing framework
o The commands named_ok, set_name and unset_name now
exist (in C
and Perl). You can use these to specify a name for tests either
individually (via named_ok
On Wed, 10 Apr 2002, Paul Millar wrote:
Hi,
The attached patch changes the way the regression testing works slightly.
The default behaviour should be the same, but there's some optional
enhancements:
o If you set WINETEST_REPORT_SUCCESS environment variable to 1,
successful tests
I know regression testing isn't as interesting as
doing real development, and so I appologize with once
again spamming the list with regression questions...
As I've been writing tests (only for the last
week or so), I realized that as we get a lot more tests,
it will be very
On Fri, Mar 29, 2002 at 11:21:23AM -, Geoffrey Hausheer wrote:
I know regression testing isn't as interesting as
doing real development, and so I appologize with once
again spamming the list with regression questions...
NP. I'm sure it helps :)
[...]
So does anyone thing
at least until I can find a good way to test
CreateProcess...
a bit out of topic (from the question), but I have an
embryonic CreateProcess test, so don't bother with that
(and there is a lot to test here)
On Fri, 29 Mar 2002, Eric Pouech wrote:
at least until I can find a good way to test
CreateProcess...
a bit out of topic (from the question), but I have an
embryonic CreateProcess test, so don't bother with that
(and there is a lot to test here)
This is interesting. How do you test
, is more likely
to draw more people to do so.
I agree. Documenting and finishing the test framework is on the list
for Wine 0.9.0. I added the corresponding tasks yesterday:
* 526 [NEW] - Document the regression testing framework
http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=526
Francois Gouget a écrit :
On Fri, 29 Mar 2002, Eric Pouech wrote:
at least until I can find a good way to test
CreateProcess...
a bit out of topic (from the question), but I have an
embryonic CreateProcess test, so don't bother with that
(and there is a lot to test here)
On Fri, 29 Mar 2002, Eric Pouech wrote:
[...]
the global test goes as :
1/ the parent creates the child
2/ the parent waits for the child to terminate
3/ the child process stores most information it can gather in a
temporary file
4/ the child terminates
5/ the parent does the final
Francois Gouget a écrit :
On Fri, 29 Mar 2002, Eric Pouech wrote:
For the parameter testing I was thinking of storing the expected argv
parameters in environment variables. Then, we need a way to tell the
child to do specific tests (maybe one more environment variable) and it
would then
On Fri, 29 Mar 2002, Eric Pouech wrote:
Francois Gouget a écrit :
On Fri, 29 Mar 2002, Eric Pouech wrote:
For the parameter testing I was thinking of storing the expected argv
parameters in environment variables. Then, we need a way to tell the
child to do specific tests (maybe one
True. So what we need is to add a function in the testing framework
so that tests can get argc/argv/envp. Seems like a reasonable approach.
I was more thinking adding some wt_argc and wt_argv, with init in main
so that we don't have to deal with the portability issues of the __argc,
__
True. So what we need is to add a function in the
testing framework
so that tests can get argc/argv/envp. Seems like a
reasonable approach.
I was more thinking adding some wt_argc and wt_argv, with init in main
so that we don't have to deal with the portability issues of
the
On Fri, 29 Mar 2002, Eric Pouech wrote:
True. So what we need is to add a function in the testing framework
so that tests can get argc/argv/envp. Seems like a reasonable approach.
I was more thinking adding some wt_argc and wt_argv, with init in main
so that we don't have to deal with
On 29 Mar 2002, Geoffrey Hausheer wrote:
True. So what we need is to add a function in the
testing framework
so that tests can get argc/argv/envp. Seems like a
reasonable approach.
I was more thinking adding some wt_argc and wt_argv, with init in main
so that we don't have to
yup... but we want to test CreateProcess, and some test cases will
change the stdout handle
But do you need to write to stdout for these tests. Do you need to
write to stdout at all for that matter?
that has to be defined. But how can you test the child gets the correct
stdout ? either
--- Paul Millar [EMAIL PROTECTED] wrote:
I've been toying with an automatic regression
testing system over the
past month or so. The results can be seen at:
http://www.astro.gla.ac.uk/users/paulm/WRT/
Currently its only using the Perl framework, which
doesn't test too much
On Wed, 20 Mar 2002, Andriy Palamarchuk wrote:
--- Paul Millar [EMAIL PROTECTED] wrote:
http://www.astro.gla.ac.uk/users/paulm/WRT/
Looks good. I don't know if we need this information
online.
True.
We could get away with just an email when something broke, but the web
interface is
I was sitting in a sitting room,
Toying with some toys,
When from a room marked Gruesome,
There came a gruesome noise.
I've been toying with an automatic regression testing system over the
past month or so. The results can be seen at:
http://www.astro.gla.ac.uk/users/paulm/WRT
Hi all,
I've been trying to track down the source of my Visual Foxpro Left
click in a window, and 'freeze' error, and with the help of Lawson
Whitney, I *think* I've managed to narrow it down to the patch that
causes it.
If I checkout wine from cvs, then do a
cvs update -D 2001-06-19
I get a
Jeremy White wrote:
Eric Pouech wrote:
Does anyone know of or have experience with free/open-source/etc tools
that allow for development and implementation of regression test suites
for GUI components? A tool called "Pet" (?) was mentioned...Anyone? ;)
1/ don't you mean TET
Title: Re: ALS Update Regression Testing
Was reading the weekly news...
Rational Visual Test would be a nice tool to use for GUI testing.
I've written a Perl wrapper for the redistributable VTest60.dll. I can't redistribute the dll, as combined with my wrapper, it would probably qualify
well, it seems there are two versions:
- a supported TETware (with annual fees)
- an unupported TET
My mistake; the unsupported TET is released under
an Artistic license, and is not so old and decrepid
as their web side would have you believe.
(You do have to go through an annoying
Patrik Stridvall wrote:
Hello Patrick:
You recently wrote on wine-devle about your "condensing-ware"
winapi_test project.
Yes. I have being otherwise occupied again, so I haven't worked
much on it lately. It works but it it currently such a gross hack
that I haven't released it
Hello Patrick:
You recently wrote on wine-devle about your "condensing-ware" winapi_test project.
Is there room in this thing for arbitrary regression tests too? We are working my
way through the semi-annual Corel mega merge and would like some way of verifying that
the bugs we (Corel and
Hello Patrick:
You recently wrote on wine-devle about your "condensing-ware"
winapi_test project.
Yes. I have being otherwise occupied again, so I haven't worked
much on it lately. It works but it it currently such a gross hack
that I haven't released it yet. It works to some extent
I will see if I find time to make a prerelease of winapi_test
later today. At least something useful currently works,
eventhough it still is a gross hack (slow and bloated).
I found some time, but not that much. :-)
Very quick install instruction, there will
surely be some mistakes.
Apply
On Sun, 21 May 2000, gerard patel wrote:
* documentation/bugreports
Regression testing using Cvs
A quick question:
-- why do we need a local CVS repository? Why can't we use the WineHQ
one?
(Sorry for asking without trying first, I feel rather leazy now... :) )
--
Dimi.
"Dimitrie O. Paun" wrote:
On Sun, 21 May 2000, gerard patel wrote:
* documentation/bugreports
Regression testing using Cvs
A quick question:
-- why do we need a local CVS repository? Why can't we use the WineHQ
one?
it's just quicker, and not depend of winehq
43 matches
Mail list logo
