--- Gerard Patel [EMAIL PROTECTED] wrote:
At 04:44 PM 08/01/2002 -0500, you wrote:
snip
(Another Pythoner, cool :) )
This has given me an idea - while I don't expect it
to be
used in Wine, I will try to write my own test progs
with it : use the *windows* python interpreter under
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Which approaches can you suggest to reach goals I
believe are important:
1) bundling - are we going to have separate
distributions - Wine with tests, tests only, Wine
only? There are a lot of cases where only one of them
is required.
My view
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
3) Organization of the unit tests in such way, so
they
can be used by other Win32 implementation
projects.
Conditional TODOs I suggested above will help to
manage different TODO lists for
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Do not understand why we need to have the command line
option. TODO_WINE will automatically detect when the
application runs under Wine. Under Windows the code in
TODO_WINE will be executed like there is no TODO.
The idea is that you might want
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
The idea is that you might want to run the TODO_WINE
tests under Wine
in Windows mode, for instance to find a problem
you'd like to work
on. You could grep for TODO_WINE in the test scripts
but this is less
convenient IMO.
Understood. IMO
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
But I think implementing it now would actually make
your life easier.
This way you wouldn't have to require some magic
call to detect you
are running on Wine, you could simply rely on the
Wine
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Almost all complexity you are talking about is already
implemented for us. Usage of the framework is very
simple, do not require from test writers anything.
They are only required to correctly use Test::Simple
(or Test::More). They don't need to
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
[...]
But adapting the framework to do what we want is IMO
more work than
simply reimplementing from scratch the few features
that we actually
need. We don't really gain anything by making the
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Could you, please, list the additional features we
need? I'll try to estimate amount of work necessary to
implement them in Test::Harness.
Basically the features I get with my 10-line makefile hack: ability to
run tests for modified dlls and their
On 8 Jan 2002, Alexandre Julliard wrote:
I personally think Perl would be a better choice, but I seem to be
pretty much the only one of this opinion.
Well, if random opinions count here, I also would prefer Perl. As much as
I hate Perl (I'm more in the Python camp), I'd hate writing
On Tue, 8 Jan 2002, Alexandre Julliard wrote:
I personally think Perl would be a better choice, but I seem to be
pretty much the only one of this opinion. In any case the most
important thing is to choose something that people are going to use,
and so far the Perl stuff isn't a success in
On Tue, 8 Jan 2002, Ove Kaaven wrote:
Well, if random opinions count here, I also would prefer Perl. As much as
I hate Perl (I'm more in the Python camp), I'd hate writing regression
tests in C much more.
(Another Pythoner, cool :) )
But if we accept tests in C, we don't loose anything. If
Dimitrie O. Paun [EMAIL PROTECTED] writes:
So, bottom line, I think you should accept whatever tests you get. If the
author gets a woody writing them in C, or using some test harness or
another, let's just consider it the motivating factor behind writing the
tests in the first place.
On Tue, 8 Jan 2002, Alexandre Julliard wrote:
Unfortunately that's not possible. If everybody uses his favorite test
harness we will soon have more of them than actual tests.
Certainly, I was exaggerating. However, we should accept tests written in C.
--
Dimi.
On 8 Jan 2002, Alexandre Julliard wrote:
Dimitrie O. Paun [EMAIL PROTECTED] writes:
So, bottom line, I think you should accept whatever tests you get. If the
author gets a woody writing them in C, or using some test harness or
another, let's just consider it the motivating factor behind
At 04:44 PM 08/01/2002 -0500, you wrote:
snip
(Another Pythoner, cool :) )
This has given me an idea - while I don't expect it to be
used in Wine, I will try to write my own test progs
with it : use the *windows* python interpreter under Wine.
From the doc, it's possible to call any win32 api
On Tue, 8 Jan 2002, Francois Gouget wrote:
The perl test framework will need a way to build a zip file of some
sort with all the necessary stuff to run the perl tests on Windows. All
we need is for this to not be confused when we add the C tests. The C
tests will need such a functionality
On Tue, 8 Jan 2002, Gerard Patel wrote:
This has given me an idea - while I don't expect it to be
used in Wine, I will try to write my own test progs
with it : use the *windows* python interpreter under Wine.
From the doc, it's possible to call any win32 api from
it using a 'calldll'
On Tue, 8 Jan 2002, Dimitrie O. Paun wrote:
[...]
Now, from the POV of Wine, we don't care (just like the kernel), if the
executable is a native binary or a #! executable. Everything else are a
few Makefile rules, which are conditional on the given
compiler/interpreter being available (which
On Wed, 9 Jan 2002, Francois Gouget wrote:
That's true on Unix because sh, perl, and C executables will just
work. But if some of your tests are sh scripts you will have trouble
running them on Windows.
Yes, but nobody really proposes writing tests in Bourne-shell. In fact,
you can't
Spent a couple of days trying to port my test to C
unit testing framework Check.
Simple tests work fine. Problems start when I try to
use multithreaded Wine tests. In one case the
framework stucks on reading from pipe. Other code
layouts have other issues. The cause may be in
incorrect pipes
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Simple tests work fine. Problems start when I try to
use multithreaded Wine tests. In one case the
framework stucks on reading from pipe. Other code
layouts have other issues. The cause may be in
incorrect pipes handling, multi-process tests
Hmm, I don't see my post in wine-devel.
Alexandre, did I send the message directly to you?
If yes, could you, please, forward to the mailing list?
Thank you.
Alexandre Julliard wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Simple tests work fine. Problems start when I try to
use
Andriy Palamarchuk [EMAIL PROTECTED] writes:
:-( I need more than one thread to catch message on system parameter
value change.
Not really, if you create a window your winproc will be called even if
it's in the same thread. But we need to make threading work in any
case.
I really like
Sylvain Petreolle wrote:
Running test1.pl returns to me :
[syl@snoop winetest]$ cd /c/winetest
[syl@snoop winetest]$ perl test1.pl
Can't locate wine.pm in @INC (@INC contains:
/usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i386-linux
--- Andriy Palamarchuk [EMAIL PROTECTED] wrote:
Bad:
5) no types checking, so errors in values, calculated
manually won't be caught :-(
Andriy Palamarchuk
__
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
On 3 Jan 2002, Alexandre Julliard wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Always succeed *under Windows*. Do you really, really,
really think all the tests will succeed under Wine
from day 1 and we will be able to maintain them
failure-free?
Absolutely. There's a very
Alexandre Julliard wrote:
Do you really, really,
really think all the tests will succeed under Wine
from day 1 and we will be able to maintain them
failure-free?
Absolutely. There's a very simple way of enforcing that: I'm not
comitting anything that causes make test to fail.
That's
On Thu, Jan 03, 2002 at 10:59:37AM -0800, Dan Kegel wrote:
Alexandre Julliard wrote:
Do you really, really,
really think all the tests will succeed under Wine
from day 1 and we will be able to maintain them
failure-free?
Absolutely. There's a very simple way of enforcing that:
On Thu, 3 Jan 2002, Dan Kegel wrote:
[...]
Francios, are your tests (from http://fgouget.free.fr/wine/booktesting-en.shtml)
part of this framework yet?
No and they will not be. The reason is that the source for these
tests are part of books and as such it is all copyrighted material.
Dan Kegel [EMAIL PROTECTED] writes:
That's great to hear, but I think you have to modify your statement a
bit -- you may want to commit new tests don't yet pass,
if they show a real flaw in Wine.
In that case the test should use a TODO mechanism or equivalent, and
it must still be possible
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Always succeed *under Windows*. Do you really,
really,
really think all the tests will succeed under Wine
from day 1 and we will be able to maintain them
failure-free?
Absolutely. There's
Andriy Palamarchuk [EMAIL PROTECTED] writes:
I don't see poing in selecting subsets of tests. From
experience - even with pretty big number of tests it
does not take long time to execute them.
A good testing suite is going to take a long time to run. My simple
atom test takes about 3 seconds
Alexandre Julliard wrote:
Dan Kegel [EMAIL PROTECTED] writes:
That's great to hear, but I think you have to modify your statement a
bit -- you may want to commit new tests don't yet pass,
if they show a real flaw in Wine.
In that case the test should use a TODO mechanism or equivalent,
On Thursday 03 January 2002 07:54 am, Andriy Palamarchuk wrote:
Alexandre Julliard wrote:
The value of unit tests is exactly in failures! The
more failures of unit tests we have - the better test
developers do their work.
The whole programming methodology exists which
dictates that you
Hi Andriy and all,
Thanks,
the scripts are running as expected yet.
--- Andriy Palamarchuk [EMAIL PROTECTED] a écrit :
Sylvain Petreolle wrote:
Running test1.pl returns to me :
[syl@snoop winetest]$ cd /c/winetest
[syl@snoop winetest]$ perl test1.pl
Can't locate wine.pm in @INC
On Thu, Jan 03, 2002 at 04:55:03PM -0500, Robert Baruch wrote:
On Thursday 03 January 2002 07:54 am, Andriy Palamarchuk wrote:
The value is when you add new functionality (and possibly new tests) and old
tests break. Then you can pinpoint the changes that caused the old tests to
break.
On Thursday 03 January 2002 06:05 pm, Andreas Mohr wrote:
On Thu, Jan 03, 2002 at 04:55:03PM -0500, Robert Baruch wrote:
The value is when you add new functionality (and possibly new tests) and
old tests break. Then you can pinpoint the changes that caused the old
tests to break. Again,
On 1 Jan 2002, Alexandre Julliard wrote:
Jeremy White [EMAIL PROTECTED] writes:
I've started playing with this, Alexandre, and I had a thought/question:
why not put the tests under 'wine/tests'? I recognize the benefit
of having a test immediately associated with the implementation.
On Wed, Jan 02, 2002 at 02:34:56AM -0800, Francois Gouget wrote:
I can think of one case that I burn to put into the Wine testing
framework: the command line/argv/argv handling. I think it
would make sense to test simultaneously:
Yes, yes, and again: yes !
Wine's cmdline handling is still
On 30 Dec 2001, Alexandre Julliard wrote:
[...]
In fact here's a 10-minute hack to add a make test target. With that
all you have to do is create a test script in dlls/xxx/tests/foo.test,
put the expected output in tests/foo.test.ref (presumably generated by
running the test under Windows),
On Wed, Jan 02, 2002 at 04:36:14AM -0800, Francois Gouget wrote:
I think what we need with this is a couple of guidelines and
documentation for potential test writers, and maybe a couple of
extensions. The following is half a proposed documentation that we could
put in the Wine Developper
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
In theory tests should be written under Windows yes.
In practice the
initial version of a test may be done on Windows,
but I'm sure people
will then modify the test under Wine without
bothering to retry under
Windows every time.
What is the
--- Francois Gouget [EMAIL PROTECTED] wrote:
[...]
What is a test
I wonder if I'm the only one who favours using
existing testing framework? Why to create something
new if you have not reviewed existing options?
Perl has big choice of tools. In previous messages I
reported about choices for
--- Francois Gouget [EMAIL PROTECTED] wrote:
[...]
A test unit can also exercise more than one aspect
of
one or more APIs. But, as a rule of thumb, a
specific
test should not exercise more than a couple to a
handful related APIs (or up to a dozen in extreme
cases). Also, more than one
Francois Gouget [EMAIL PROTECTED] writes:
I think what we need with this is a couple of guidelines and
documentation for potential test writers, and maybe a couple of
extensions. The following is half a proposed documentation that we could
put in the Wine Developper Guide, and half a
On Wed, Jan 02, 2002 at 10:20:25AM -0800, Alexandre Julliard wrote:
Francois Gouget [EMAIL PROTECTED] writes:
* it should be easy to correlate with the source of the test. For
instance if a check fails, it would be a good idea to print a message
that can easily be grepped in the source
* its exit code
* text output on either or both of stdout and stderr, both of which are
normally redirected to a file called 'xxx.out'.
A test succeeds if:
* its exit code is 0
* and its output, 'xxx.out' matches the reference output according to
the rules described later.
I think that
Andriy Palamarchuk [EMAIL PROTECTED] writes:
I suggest to use explicit checks and print descriptive
messages in case of falure. I agree, this approach is
more labour-intensive, especially for tests using IPC.
It is also much more maintainable as soon as you coded
it. Everything, including
Francois Gouget [EMAIL PROTECTED] writes:
I am not sure about using asserts. In the case where one calls the
same API ten times with different parameters, it would probably be
better to still do all ten tests even if the second call fails. This way
the developper debugging things
On 2 Jan 2002, Alexandre Julliard wrote:
Francois Gouget [EMAIL PROTECTED] writes:
I am not sure about using asserts. In the case where one calls the
same API ten times with different parameters, it would probably be
better to still do all ten tests even if the second call fails. This
On 2002.01.02 14:12 Jeremy White wrote:
[big snip]
1. Cygwin installation has *dramatically* improved.
Getting a full working toolchain is no longer
a big pain in the rear end, it's actually pretty easy.
[big snip]
Well, as I mentioned the other day... I have recently
On Wed, Jan 02, 2002 at 11:40:40AM -0800, Alexandre Julliard wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
I suggest to use explicit checks and print descriptive
messages in case of falure. I agree, this approach is
more labour-intensive, especially for tests using IPC.
It is
The final attempt to solicit feedback for my
suggestion to use existing testing framework.
Want to bring to your attention testing framework
Test::Simple. I think you'll like this one the most
because it implements exactly the ideas you suggested
earlier, plus some more.
You can play with the
On Wed, 2 Jan 2002, Andreas Mohr wrote:
[...]
What is needed most is a two sample tests:
* one simple console based test
* another one involving some GUI stuff
No !
We need Win32 GUI, Win32 console and Win16.
Why is it necessary to separate Win16 from the rest?
On Windows it
Running test1.pl returns to me :
[syl@snoop winetest]$ cd /c/winetest
[syl@snoop winetest]$ perl test1.pl
Can't locate wine.pm in @INC (@INC contains:
/usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i386-linux
/usr/lib/perl5/site_perl/5.6.0
Andriy Palamarchuk [EMAIL PROTECTED] writes:
1) look at file test1.pl. It implements exactly the
functionality of existing test.pl module with using
Test::Simple framework. The only change I made are
descriptive error messages for the first few tests.
Output of test1.pl:
ok 1 - Valid
In fact here's a 10-minute hack to add a make test target. With that
all you have to do is create a test script in dlls/xxx/tests/foo.test,
put the expected output in tests/foo.test.ref (presumably generated by
running the test under Windows), add your script to the makefile and
run make test.
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Before I was confident the tests would be developed under Windows and
then run under Wine. You described reverse situation.
To create a test people will have to use Windows to check it works
properly. Of course all the tests must succeed under
Jeremy White [EMAIL PROTECTED] writes:
I've started playing with this, Alexandre, and I had a thought/question:
why not put the tests under 'wine/tests'? I recognize the benefit
of having a test immediately associated with the implementation.
But, I would argue
a) that not all
I don't think we should maintain a Windows make hierarchy, at least
not manually. If we have to ship Windows makefiles they should be
generated from the Wine makefiles (or both types of makefile generated
from some other source file). Asking people to keep two hierarchies in
sync won't work.
Jeremy White [EMAIL PROTECTED] writes:
Ideally, we would have a 'winetest.zip' such that all I would
have to do is install Perl, and then I'd have a nice set of
sample test scripts I could run/modify/tweak to my hearts
satisfaction.
Exactly, yes. If possible winetest.zip should also include
One more point in favour of C-based tests. They will
be very useful in porting Wine to non-Intel platforms.
C tests will help to test both - execution of Windows
applications under processor emulator and compilation
of Windows applications with Winelib.
1. It is much easier to install under
Andriy Palamarchuk [EMAIL PROTECTED] writes:
It seems the problem is not so big. It will be sufficient to run the
binary, compiled under Windows not more often than once a month.
But it won't compile. Once we have a simple environment in Wine where
you run make test and everything happens
Alexandre Julliard wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
It seems the problem is not so big. It will be sufficient to run the
binary, compiled under Windows not more often than once a month.
But it won't compile. Once we have a simple environment in Wine where
you run make
Andriy Palamarchuk [EMAIL PROTECTED] writes:
No, ability to call W32 API functions is not
considered a unit test infrastracture. I may say Wine
has such infrastructure for C since 1993 :-). From
this point of view Andreas test application provides
more support for unit tests than plain Perl
Andriy Palamarchuk [EMAIL PROTECTED] writes:
1) The discussion started from John Sturtz post, who
created the Perl module for Win32 functions.
Discussion what is better - C or Perl for unit testing
started later as I understand there was no conclusion.
Now I can assume that this topic was
On 2001.12.30 15:34 Alexandre Julliard wrote:
2. The scripts are independent from the compilation environment, which
allows testing binary compatibility. In C you have to compile the
tests under Wine using the Wine headers, which means you can't spot
wrong definitions in the headers
[omitting comments about very nice make test framework]
On Sun, Dec 30, 2001 at 12:34:06PM -0800, Alexandre Julliard wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
1) The discussion started from John Sturtz post, who
created the Perl module for Win32 functions.
Discussion what is
Andreas Mohr [EMAIL PROTECTED] writes:
Hmm, and different winver settings for testing of the behaviour of
different Wine --winver settings and adapting to different Windows versions
are possible with this framework, too ?
In its current state it uses the default Wine config from ~/.wine so
Responding to Alexandre and Jeremy.
Alexandre Julliard wrote:
Basically the argument is that some sort
of scripting language is better than plain C for two reasons:
1. It is much easier to install under Windows than a full development
environment, and we don't have to worry about
Simplicity is one of the goals of the testing
framework, but besides being simple the framework
should be powerful enough for such big project.
I'm looking for existing library which would suit our
needs.
Unit test framework Check looks promising. It
provides many features which I'd love to
Andriy (and all),
I think you have dismissed winetest much too quickly.
We spent a considerable amount of energy thinking
about a test harness (largely because one of our investors
felt passionately that it was vital), so not only did
we have the public conversations you saw on wine-devel,
we
Alexandre Julliard wrote:
Andreas Mohr [EMAIL PROTECTED] writes:
Please comment on both my intended posting and the
way I programmed the first
version of the test suite (I'm not extremely happy
with the current program;
if you have any improvements, then get them here
ASAP !).
Look at
On Thu, Dec 27, 2001 at 07:38:24AM -0800, Andriy Palamarchuk wrote:
Because of the goals I'm more inclined to use C-based
test suite. IMHO it is better suited for existing Wine
developers audience and will provide us much bigger
code pool. I'm even ready to have tests in both - Perl
and C.
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Just looked at the tool. It only provides gateway from
Perl to wine API functions, right?
Yes, though a lot of higher-level stuff could be added to it once
people start using it.
The C vs. Perl question has been debated already, please check the
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
The truth is that a lot of people are
willing to setup a
testing infrastructure, but nobody is willing to
write the actual
tests.
Counterexamples:
1) I suspect that you try to run the code you develop
before committing it to CVS ;-) You work
On Thu, 27 Dec 2001, Andriy Palamarchuk wrote:
[... Perl/C pros and cons for testing]
I think you summarised the pros and cons of both options quite
well. I would add just one thing against perl in its current form: AFAIK
(but it may have changed since), the current perl framework does not
On 27 Dec 2001, Alexandre Julliard wrote:
[...]
The C vs. Perl question has been debated already, please check the
archive. The truth is that a lot of people are willing to setup a
testing infrastructure, but nobody is willing to write the actual
tests.
I don't know if it is that noone
I looked at thread Perl/Wine extension for perusal
ran on February, 2001. Want to bring some information
from that thread to this discussion:
1) The discussion started from John Sturtz post, who
created the Perl module for Win32 functions.
Discussion what is better - C or Perl for unit testing
On Friday 28 December 2001 05:00, Andreas Mohr wrote:
Yes, IMHO we really need a C based test.
I'd go along with this. It seems that a variety of tests, written and
contributed by a variety of people, and thus written in a variety of
mutually inconsistent and collectively odd ways, is
On Fri, Dec 28, 2001 at 12:49:54PM +1300, Geoff Thorpe wrote:
[voting for a simple test interface]
If a testing framework is anything more complicated - the only people
working on the test suites will be whoever defines/understands the test
framework specification and the hard-core wine
Andreas Mohr wrote:
I guess we really should change our development
model from trying tons of
programs to *systematically* testing functions and
Windows mechanisms now.
If we can show everyone where stuff is failing, it
might be a lot easier
to attract new people.
I *completely* support this
C Unit test frameworks I found after a quick search:
http://check.sourceforge.net/
http://people.codefactory.se/~spotty/cunit/
http://freshmeat.net/projects/autounit/
C++:
http://sourceforge.net/projects/cppunit/
Thanks,
Andriy Palamarchuk
__
Do
On Wed, Dec 26, 2001 at 10:07:20AM -0800, Andriy Palamarchuk wrote:
Andreas Mohr wrote:
I guess we really should change our development
model from trying tons of
programs to *systematically* testing functions and
Windows mechanisms now.
If we can show everyone where stuff is failing, it
--- Andreas Mohr [EMAIL PROTECTED] wrote:
On Wed, Dec 26, 2001 at 10:07:20AM -0800, Andriy
Palamarchuk wrote:
Andreas Mohr wrote:
[... skipped ...]
- it would be better if the suite print summary
information and information about failed tests
only
Yep. Current output is something
Andreas Mohr [EMAIL PROTECTED] writes:
I attached a preview of the posting I intend to post on *tons* of Windows
devel newsgroups (Call For Volunteers). That way we might actually get
hold of hundreds of Windows developers helping us implement a complete
test suite (complete tests of up to
On Wed, Dec 26, 2001 at 10:26:27AM -0800, Andriy Palamarchuk wrote:
C Unit test frameworks I found after a quick search:
http://check.sourceforge.net/
http://people.codefactory.se/~spotty/cunit/
http://freshmeat.net/projects/autounit/
C++:
http://sourceforge.net/projects/cppunit/
Seen on
I wholeheartedly agree with you.
I think that both approaches (application oriented, and API oriented)
are necessary.
* We need the application oriented approach because this makes Wine
useful to people now. But maybe we should focus more on specific
applications: getting a few
89 matches
Mail list logo
