Multi-version installs, happyness?, feedback please!

jmf1 · May 23, 2007, 6:47am

With the release of wxPython 2.5.3, wxPython came with
a multi-version installs and a version selection mechanism.

Now, two years later, what is your experience with this
feature?

···

======

My experience:

- I gave up with this feature and do no more implement a version
selection in my code.

- I'm using it from time to time, solely when I wish to test
the ansi/unicode builds with the same "numbered" version.
Eg. 2.8.4-ansi / 2.8.4-unicode.

- The mismatch between "odd numbered"" and "even numbered" releases
(the so called stable/unstable? releases) has made this *very nice*
feature unusable.

- To summurize: PLEASE, LET ME SELECT THE WXPYTHON 2.8.N I WISH

... and do not tell me a 2.2m.n+1 is just a debugged release of a 2.2m.n,
they are just too different.

Regards to all

Jean-Michel Fauth, Switzerland

Christian1 · May 23, 2007, 7:05am

jmf wrote:

With the release of wxPython 2.5.3, wxPython came with
a multi-version installs and a version selection mechanism.

Now, two years later, what is your experience with this
feature?

======

My experience:

- I gave up with this feature and do no more implement a version
selection in my code.

- I'm using it from time to time, solely when I wish to test
the ansi/unicode builds with the same "numbered" version.
Eg. 2.8.4-ansi / 2.8.4-unicode.

why would one use the ansi version?

- The mismatch between "odd numbered"" and "even numbered" releases
(the so called stable/unstable? releases) has made this *very nice*
feature unusable.

- To summurize: PLEASE, LET ME SELECT THE WXPYTHON 2.8.N I WISH

why do you want to create software which depends on the minor version number? In
casre you're the only user of your software then why don't you install the
version you want?

I find it quite useful to easily adapt software to support a new version of
wxpython and I thought this is what it was meant for.

Christian

Werner_F_Bruhin1 · May 23, 2007, 10:04am

Hi Christian,

Christian K wrote:

jmf wrote:

With the release of wxPython 2.5.3, wxPython came with
a multi-version installs and a version selection mechanism.

Now, two years later, what is your experience with this
feature?

======

My experience:

- I gave up with this feature and do no more implement a version
selection in my code.

- I'm using it from time to time, solely when I wish to test
the ansi/unicode builds with the same "numbered" version.
Eg. 2.8.4-ansi / 2.8.4-unicode.

As my shareware goes out build with py2exe I don't use selection in my code. However multi version install is extremely useful during development, one can quickly test a new version without affecting ones own code.

Jean-Michel's request to be able to "multi install" even a minor version would be very very useful during testing. I don't mind if the installer overwrites as one can easily rename the folder one self, but it would be very nice if one could select even a minor version.

why would one use the ansi version?

As some of us are not yet ready to use the Unicode version, e.g. I will switch over but it is work (database conversion, retesting ...) and there are other more pressing issues.

Werner

Kevin_Ollivier3 · May 23, 2007, 2:41pm

Hi Jean-Michael,

With the release of wxPython 2.5.3, wxPython came with
a multi-version installs and a version selection mechanism.

Now, two years later, what is your experience with this
feature?

======

My experience:

- I gave up with this feature and do no more implement a version
selection in my code.

- I'm using it from time to time, solely when I wish to test
the ansi/unicode builds with the same "numbered" version.
Eg. 2.8.4-ansi / 2.8.4-unicode.

- The mismatch between "odd numbered"" and "even numbered" releases
(the so called stable/unstable? releases) has made this *very nice*
feature unusable.

What mismatch?

- To summurize: PLEASE, LET ME SELECT THE WXPYTHON 2.8.N I WISH

... and do not tell me a 2.2m.n+1 is just a debugged release of a 2.2m.n,
they are just too different.

Well, it is definitely supposed to be, so if it's not, you've found a bug. What you're asking for is a way to ignore bugs in later versions of a stable release series, but I really don't think we should make that super easy to do, because I think wxPython would be a lot better off if people reported bugs when they found them so that we could once again have the stable releases working as expected. Have you reported all the differences you found?

We currently don't have automated testing in place, and so unfortunately it's not uncommon to get regressions in the codebase, but until we have an automated solution in place we are very, very dependent on users reporting bugs that they found to improve wxPython. Robin, myself, and a few other people really can't test hard enough to find all the problems in wxPython ourselves.

Regards,

Kevin

···

On May 22, 2007, at 11:47 PM, jmf wrote:

Regards to all

Jean-Michel Fauth, Switzerland

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Don_Dwiggins · May 23, 2007, 4:08pm

Kevin Ollivier wrote:

We currently don't have automated testing in place, and so unfortunately it's not uncommon to get regressions in the codebase, but until we have an automated solution in place we are very, very dependent on users reporting bugs that they found to improve wxPython. Robin, myself, and a few other people really can't test hard enough to find all the problems in wxPython ourselves.

This seems to suggest that you're working on an automated way to test wxPython components; is this right? If so, could it also be used for automated testing of wxPython applications? I generally write my apps in a semi-MVC style that allows automated unit testing of the model, but it'd be neat to be able to do the same for the GUI component.

···

--
Don Dwiggins
Advanced Publishing Technology

Josiah_Carlson · May 23, 2007, 4:28pm

There's an accepted Google SoC project for building a testing framework:
http://code.google.com/soc/wxpython/appinfo.html?csaid=830C0C2A7F545880

We'll see what is produced by the end of the summer.

- Josiah

···

Don Dwiggins <ddwiggins@advpubtech.com> wrote:

Kevin Ollivier wrote:
> We currently don't have automated testing in place, and so unfortunately
> it's not uncommon to get regressions in the codebase, but until we have
> an automated solution in place we are very, very dependent on users
> reporting bugs that they found to improve wxPython. Robin, myself, and a
> few other people really can't test hard enough to find all the problems
> in wxPython ourselves.

This seems to suggest that you're working on an automated way to test
wxPython components; is this right? If so, could it also be used for
automated testing of wxPython applications? I generally write my apps
in a semi-MVC style that allows automated unit testing of the model, but
it'd be neat to be able to do the same for the GUI component.

Kevin_Ollivier3 · May 23, 2007, 4:31pm

Hi Don,

Kevin Ollivier wrote:

We currently don't have automated testing in place, and so unfortunately it's not uncommon to get regressions in the codebase, but until we have an automated solution in place we are very, very dependent on users reporting bugs that they found to improve wxPython. Robin, myself, and a few other people really can't test hard enough to find all the problems in wxPython ourselves.

This seems to suggest that you're working on an automated way to test wxPython components; is this right?

Yup, it's one of the wxPython SoC projects. Frank Tobia is currently researching what tools are out there and getting ready to start work on the project. There's a start on a wiki page here:

http://wiki.wxpython.org/GUI_Unit_Testing_Project

If so, could it also be used for automated testing of wxPython applications?

That is the idea, yes, and one of the goals we've stated for the project is actually a tutorial on how wxPython users can use this themselves. In the meantime, you might want to check out Zephyr (links can be found on the above Wiki page), an automated GUI testing tool that's actually written using wxWidgets. (I found it by accident while browsing through wiki.wxwidgets.org) There's only a Windows binary (though there's Linux support in the project's SVN tree), and the developer seems to have moved on, but the Windows version works so well that I'm probably going to convert the project to use Bakefile so that we can build it on Win,Mac and Linux. It's built in a manner that's very simple but allows you to test almost any action, so long as it produces a visual result. It also looks like it could support Mac by implementing a dozen or so functions using Mac-specific code.

I generally write my apps in a semi-MVC style that allows automated unit testing of the model, but it'd be neat to be able to do the same for the GUI component.

If you give Zephyr a try, please let me know how you like it! On the homepage there's a demo movie on how to use it - you can literally be up and using it in 5 minutes. The coolest part is that it can test any app, not just wxPython apps.

Regards,

Kevin

···

On May 23, 2007, at 9:08 AM, Don Dwiggins wrote:

--
Don Dwiggins
Advanced Publishing Technology

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Chris_Barker1 · May 23, 2007, 4:58pm

jmf wrote:

- I gave up with this feature and do no more implement a version
selection in my code.

I do you it less than I used to -- the days of change in the 2.5 series really called for it!

- To summurize: PLEASE, LET ME SELECT THE WXPYTHON 2.8.N I WISH

I totally agree. I really miss this.

... and do not tell me a 2.2m.n+1 is just a debugged release of a 2.2m.n,
they are just too different.

Well, in theory, they are, but when a new release comes out (particularly a pre-release), I like to be able to test it easily, without breaking any existing running code.

Christian K wrote:

why do you want to create software which depends on the minor version number?

I don't, but I do want to test software that way. You can always leave off the third version number if you don't want to, which is what I'd always do with anything I release (or even use in "production" mode my self).

Key is that the third digit has always been optional -- but why remove functionality?

Kevin Ollivier wrote:

What you're asking for is a way to ignore bugs in later versions of
a stable release series, but I really don't think we should make that super easy to do, because I think wxPython would be a lot better off if people reported bugs when they found them so that we could once again have the stable releases working as expected.

But having this option makes it EASIER to test, therefor I'll be more likely to do it, and we'll find regressions more quickly.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Kevin_Ollivier3 · May 23, 2007, 6:16pm

Hi Chris,

jmf wrote:

- I gave up with this feature and do no more implement a version
selection in my code.

I do you it less than I used to -- the days of change in the 2.5 series really called for it!

- To summurize: PLEASE, LET ME SELECT THE WXPYTHON 2.8.N I WISH

I totally agree. I really miss this.

... and do not tell me a 2.2m.n+1 is just a debugged release of a 2.2m.n,
they are just too different.

Well, in theory, they are, but when a new release comes out (particularly a pre-release), I like to be able to test it easily, without breaking any existing running code.

Why do you have to break existing code to test?

Christian K wrote:

why do you want to create software which depends on the minor version number?

I don't, but I do want to test software that way. You can always leave off the third version number if you don't want to, which is what I'd always do with anything I release (or even use in "production" mode my self).

Key is that the third digit has always been optional -- but why remove functionality?

Kevin Ollivier wrote:

What you're asking for is a way to ignore bugs in later versions of
a stable release series, but I really don't think we should make that super easy to do, because I think wxPython would be a lot better off if people reported bugs when they found them so that we could once again have the stable releases working as expected.

But having this option makes it EASIER to test, therefor I'll be more likely to do it, and we'll find regressions more quickly.

I wouldn't find it easier given the number of apps/scripts I work with, but regardless, the real issue is that this method can be confusing; if you install the latest pre-release but forget to update your wxversion.select statements accordingly, you'll *think* you're testing the pre-release when actually you're "testing" the last official release (or whatever 2.8 release you've selected). How can you guarantee that won't happen?

And what about a tester who doesn't realize the script(s) s/he is testing call wxversion.select? You really don't think that people would run those scripts (e.g. Boa, DrPython, etc.) and report that they pass tests, all the while not realizing there's a 'wxversion.select('2.8.3.0') in there?

I see why you'd be interested in doing this, but I think there's a real potential for problems being caused by this, and I think there are other ways to address the issue.

For example, if you're concerned about being set back on your project due to a pre-release breaking your apps, set up a "clean room" environment - e.g. a user account, virtual machine, etc. that is setup just to test, and just always install the latest pre-release on that user account. Switch to that account when you want to test, and then switch back to your "deployment" environment when you want to go back to 'regular work'. It will just take a moment. This way you can always evaluate any upgrade before committing to it, and if it does break something, you can just note (or report) that and re-evaluate the new version (or figure out how to fix your app to work with the new version) at your leisure. It's true that wouldn't work well on OS X (thanks to the hardcoded system install paths), but on Windows it should be as simple as using a different dir to install the 'test' Python into. On OS X, if we could figure out how to install wxPython to a different location, you could use DYLD_LIBRARY_PATH and PYTHONPATH to switch on/switch off, which IMHO would be quite easy and a one-time thing.

Personally, I think installing a new version on your deployment setup isn't technically testing - it's upgrading. You should never do that unless you're prepared to deal with any breakage that ensues.

Regards,

Kevin

···

On May 23, 2007, at 9:58 AM, Christopher Barker wrote:

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Andrea_Gavana · May 23, 2007, 6:30pm

Hi Jean-Michel and All,

With the release of wxPython 2.5.3, wxPython came with
a multi-version installs and a version selection mechanism.

Now, two years later, what is your experience with this
feature?

======

My experience:

- I gave up with this feature and do no more implement a version
selection in my code.

- I'm using it from time to time, solely when I wish to test
the ansi/unicode builds with the same "numbered" version.
Eg. 2.8.4-ansi / 2.8.4-unicode.

- The mismatch between "odd numbered"" and "even numbered" releases
(the so called stable/unstable? releases) has made this *very nice*
feature unusable.

- To summurize: PLEASE, LET ME SELECT THE WXPYTHON 2.8.N I WISH

... and do not tell me a 2.2m.n+1 is just a debugged release of a 2.2m.n,
they are just too different.

Uhm, I don't really see where the problem is. I agree with Kevin's
statement about the difference between "testing" and "upgrading". What
I usually do when I install a new pre-release (or official 3rd digit
release), is to GUI-testing my applications and my widgets, actually
*using* them and with some rough automagic GUI-testing scripts. If and
when I find something strange, wxPython-dependent, I simply report the
bug and switch back to the previous stable release.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.virgilio.it/infinity77/

···

On 5/23/07, jmf wrote:

Chris_Barker1 · May 23, 2007, 7:34pm

Kevin Ollivier wrote:

Key is that the third digit has always been optional -- but why remove functionality?

But having this option makes it EASIER to test, therefor I'll be more likely to do it, and we'll find regressions more quickly.

I wouldn't find it easier given the number of apps/scripts I work with,

We all have different needs and preferences.

set up a "clean room" environment - e.g. a user account, virtual machine, etc. that is setup just to test, and just always install the latest pre-release on that user account.

now THAT's a lot of work!!

I guess the issue is social, not technical -- we don't want to allow wxversion.select to work for minor revisions, because we think it might cause problems if people use that feature.

Personally, I think we should give people rope, and let them hang themselves if they want -- but I guess if I really thought that I'd be writing C!

Personally, I think installing a new version on your deployment setup isn't technically testing - it's upgrading. You should never do that unless you're prepared to deal with any breakage that ensues.

well yes, but wxversion makes it easier to make it testing, rather than upgrading. I agree with JMF, I'd rather edit a line at the top of my script than mess around with changing *.pth files, re-naming dirs, or setting up virtual machines.

-CHB

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Paul_McNett · May 23, 2007, 8:04pm

Christopher Barker wrote:

I guess the issue is social, not technical -- we don't want to allow wxversion.select to work for minor revisions, because we think it might cause problems if people use that feature.

Personally, I think we should give people rope, and let them hang themselves if they want -- but I guess if I really thought that I'd be writing C!

It occurs to me that it wouldn't be difficult to implement a wxversion.select("2.8.4.4", forceMinor=True) or something like that. Then, the feature would only work if the user explicitly demanded it.

It seems that people have slightly overlapping/varying uses for wxversion, but it also seems that with some minor tweaks, everyone could be happy.

···

--
pkm ~ http://paulmcnett.com

Robin · May 23, 2007, 9:43pm

Werner F. Bruhin wrote:

Jean-Michel's request to be able to "multi install" even a minor version would be very very useful during testing. I don't mind if the installer overwrites as one can easily rename the folder one self, but it would be very nice if one could select even a minor version.

It should already support that. If you change the dir names to include the minor version, or even all 4 version components, and then specify all 4 components in the select call, then it should choose the right one. Where it can get fuzzy is when there isn't an exact match and it tries to make the best guess.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Kevin_Ollivier3 · May 23, 2007, 9:58pm

Hi Chris,

Kevin Ollivier wrote:

Key is that the third digit has always been optional -- but why remove functionality?

But having this option makes it EASIER to test, therefor I'll be more likely to do it, and we'll find regressions more quickly.

I wouldn't find it easier given the number of apps/scripts I work with,

We all have different needs and preferences.

set up a "clean room" environment - e.g. a user account, virtual machine, etc. that is setup just to test, and just always install the latest pre-release on that user account.

now THAT's a lot of work!!

Setting up a new user account and installing Python with a few extensions on it? It's a one time task that takes about 5 minutes to do. And logging out and in doesn't take all that much longer than editing scripts. Plus, it's more reliable.

I guess the issue is social, not technical -- we don't want to allow wxversion.select to work for minor revisions, because we think it might cause problems if people use that feature.

Personally, I think we should give people rope, and let them hang themselves if they want -- but I guess if I really thought that I'd be writing C!

Honestly, I don't think many people will use this rope even if we give it to them, and there are alternative solutions that really aren't too much work for the user. I've setup testing user accounts before and I didn't exactly feel like it was a huge task.

For my own part, I'd rather spend whatever time I have to work on wxPython on solving issues that affect many users (or improve wxPython's appeal to new users), of which there are quite many. For stuff with less overall impact, my personal philosophy is "scratch your own itch".

Personally, I think installing a new version on your deployment setup isn't technically testing - it's upgrading. You should never do that unless you're prepared to deal with any breakage that ensues.

well yes, but wxversion makes it easier to make it testing, rather than upgrading. I agree with JMF, I'd rather edit a line at the top of my script than mess around with changing *.pth files, re-naming dirs, or setting up virtual machines.

You don't have to do any of that in most cases. I really did not have any major issues when I setup testing user accounts, and I'd like to know why it would be so much work for you.

Regards,

Kevin

···

On May 23, 2007, at 12:34 PM, Christopher Barker wrote:

-CHB

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Desilets_Alain · May 24, 2007, 12:46pm

I and some collegues at NRC (Mark Vidger, ) are working on a autoamted testing framework for wxPython applications. The framework is called wxManipulators. It allows you to programmatically manipulate wxWindows widgets "from the inside".

For example, if you want to write a Python script that clicks on a button which is instantiated as a variable called someButton, you would write something that looks like this:

wxManipulators.ButtonManipulator(someButton).click()

When this statement is executed, it's EXACTLY as if the end user had clicked on the graphical button.

We are starting to use the framework for our own projects and it's a bit early to tell how useful it is. But if others on this list are interested, we could maybe release it already (I'd have to discuss this with my collegues). For sure, you could use the framework to test wxWindows itself. You would basically write some dummy wxWindows app, manipulate its widgets using wxManipulators, and then make sure that the dummy app behaved as expected.

···

----
Alain Désilets, MASc
Agent de recherches/Research Officer
Institut de technologie de l'information du CNRC /
NRC Institute for Information Technology

alain.desilets@nrc-cnrc.gc.ca
Tél/Tel (613) 990-2813
Facsimile/télécopieur: (613) 952-7151

Conseil national de recherches Canada, M50, 1200 chemin Montréal,
Ottawa (Ontario) K1A 0R6
National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
K1A 0R6

Gouvernement du Canada | Government of Canada

-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Don Dwiggins
Sent: May 23, 2007 12:08 PM
To: wxpython-users@lists.wxwidgets.org
Subject: [wxPython-users] Automated testing of wxPython

Kevin Ollivier wrote:
> We currently don't have automated testing in place, and so
> unfortunately it's not uncommon to get regressions in the codebase,
> but until we have an automated solution in place we are very, very
> dependent on users reporting bugs that they found to
improve wxPython.
> Robin, myself, and a few other people really can't test
hard enough to
> find all the problems in wxPython ourselves.

This seems to suggest that you're working on an automated way
to test wxPython components; is this right? If so, could it
also be used for automated testing of wxPython applications?
I generally write my apps in a semi-MVC style that allows
automated unit testing of the model, but it'd be neat to be
able to do the same for the GUI component.

--
Don Dwiggins
Advanced Publishing Technology

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

Mike_Driscoll1 · May 24, 2007, 2:00pm

From: Kevin Ollivier [mailto:kevino@theolliviers.com]
Sent: Wednesday, May 23, 2007 4:59 PM
To: wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] Multi-version installs,
happyness?, feedback please!

Hi Chris,

> Kevin Ollivier wrote:
>>> Key is that the third digit has always been optional -- but why
>>> remove functionality?
>
>>> But having this option makes it EASIER to test, therefor I'll be
>>> more likely to do it, and we'll find regressions more quickly.
>> I wouldn't find it easier given the number of apps/scripts I work
>> with,
>
> We all have different needs and preferences.
>
>> set up a "clean room" environment - e.g. a user account, virtual
>> machine, etc. that is setup just to test, and just always
install the
>> latest pre-release on that user account.
>
> now THAT's a lot of work!!

Setting up a new user account and installing Python with a
few extensions on it? It's a one time task that takes about 5
minutes to do. And logging out and in doesn't take all that
much longer than editing scripts. Plus, it's more reliable.

I use VMWare Virtual machines all the time for testing scripts and
checking out various bits of software, not to mention checking attachments
to see if they're viruses. While I haven't tried multiple versions of
Python or wxPython this way, it's extremely easy to do and if anything
causes a problem, you can roll back all the changes with a press of the
button.

If you have a fast machine, it only takes the time to install the VM
product, the host OS and the software you want on it. Take a snapshot and
then get testing!

> I guess the issue is social, not technical -- we don't want
to allow
> wxversion.select to work for minor revisions, because we think it
> might cause problems if people use that feature.
>
> Personally, I think we should give people rope, and let them hang
> themselves if they want -- but I guess if I really thought
that I'd be
> writing C!

Honestly, I don't think many people will use this rope even
if we give it to them, and there are alternative solutions
that really aren't too much work for the user. I've setup
testing user accounts before and I didn't exactly feel like
it was a huge task.

For my own part, I'd rather spend whatever time I have to
work on wxPython on solving issues that affect many users (or
improve wxPython's appeal to new users), of which there are
quite many. For stuff with less overall impact, my personal
philosophy is "scratch your own itch".

>> Personally, I think installing a new version on your
deployment setup
>> isn't technically testing - it's upgrading. You should
never do that
>> unless you're prepared to deal with any breakage that ensues.
>
> well yes, but wxversion makes it easier to make it testing, rather
> than upgrading. I agree with JMF, I'd rather edit a line at
the top of
> my script than mess around with changing *.pth files,
re-naming dirs,
> or setting up virtual machines.

You don't have to do any of that in most cases. I really did
not have any major issues when I setup testing user accounts,
and I'd like to know why it would be so much work for you.

Regards,

Kevin

Mike

···

-----Original Message-----
On May 23, 2007, at 12:34 PM, Christopher Barker wrote:

Kevin_Ollivier3 · May 24, 2007, 2:12pm

Hi Alain,

I and some collegues at NRC (Mark Vidger, ) are working on a autoamted testing framework for wxPython applications. The framework is called wxManipulators. It allows you to programmatically manipulate wxWindows widgets "from the inside".

For example, if you want to write a Python script that clicks on a button which is instantiated as a variable called someButton, you would write something that looks like this:

wxManipulators.ButtonManipulator(someButton).click()

When this statement is executed, it's EXACTLY as if the end user had clicked on the graphical button.

We are starting to use the framework for our own projects and it's a bit early to tell how useful it is. But if others on this list are interested, we could maybe release it already (I'd have to discuss this with my collegues). For sure, you could use the framework to test wxWindows itself. You would basically write some dummy wxWindows app, manipulate its widgets using wxManipulators, and then make sure that the dummy app behaved as expected.

Are you familiar with the work being done by Reinhold Fureder? It sounds like quite a similar project. You can see the project here:

http://www.wefi.net/swWxGuiTesting/

In any case, I'd love to see such a project that works for Win, Linux and Mac and is accessible from wxPython.

Thanks,

Kevin

···

On May 24, 2007, at 5:46 AM, Desilets, Alain wrote:

----
Alain Désilets, MASc
Agent de recherches/Research Officer
Institut de technologie de l'information du CNRC /
NRC Institute for Information Technology

alain.desilets@nrc-cnrc.gc.ca
Tél/Tel (613) 990-2813
Facsimile/télécopieur: (613) 952-7151

Conseil national de recherches Canada, M50, 1200 chemin Montréal,
Ottawa (Ontario) K1A 0R6
National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
K1A 0R6

Gouvernement du Canada | Government of Canada

-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Don Dwiggins
Sent: May 23, 2007 12:08 PM
To: wxpython-users@lists.wxwidgets.org
Subject: [wxPython-users] Automated testing of wxPython

Kevin Ollivier wrote:

We currently don't have automated testing in place, and so
unfortunately it's not uncommon to get regressions in the codebase,
but until we have an automated solution in place we are very, very
dependent on users reporting bugs that they found to

improve wxPython.

Robin, myself, and a few other people really can't test

hard enough to

find all the problems in wxPython ourselves.

This seems to suggest that you're working on an automated way
to test wxPython components; is this right? If so, could it
also be used for automated testing of wxPython applications?
I generally write my apps in a semi-MVC style that allows
automated unit testing of the model, but it'd be neat to be
able to do the same for the GUI component.

--
Don Dwiggins
Advanced Publishing Technology

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Chris_Barker1 · May 25, 2007, 6:10pm

I think this thread has been beaten to death, and in any case, it looks like I can do what I want now any (thanks Robin). But I do have one useful thing to add (skip to the bottom now...)

Kevin Ollivier wrote:

now THAT's a lot of work!!

Setting up a new user account and installing Python with a few extensions on it?

That's not much work, but then you also need to get the code to the stuff you need to test in the new account, and keep in it sync (not bad, as I use SVN for most stuff anyway). But another issue is that I always install packages into the system python so a different user is using the same thing anyway, and I know it can be a pain (though not that much of one) to install stuff locally to a user.

So all in all, this still looks like more work than changing a couple characters in a script.

Maybe this could be helpful, though:

make testing environment, and away you go. Probably good for testing different combinations of of separate packages too. (MPL 0.7 and 0.9 with wxPython2.6 and 2.8, for instance)

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Kevin_Ollivier3 · May 25, 2007, 6:47pm

Hi Chris,

I think this thread has been beaten to death, and in any case, it looks like I can do what I want now any (thanks Robin). But I do have one useful thing to add (skip to the bottom now...)

Kevin Ollivier wrote:

now THAT's a lot of work!!

Setting up a new user account and installing Python with a few extensions on it?

That's not much work, but then you also need to get the code to the stuff you need to test in the new account, and keep in it sync (not bad, as I use SVN for most stuff anyway). But another issue is that I always install packages into the system python so a different user is using the same thing anyway, and I know it can be a pain (though not that much of one) to install stuff locally to a user.

So all in all, this still looks like more work than changing a couple characters in a script.

Yes, but it's also much less error-prone, which is my point. If you want to take a shortcut and assume the risks involved to get things going quickly, that's your business, but I don't think the wxPython project should sanction that behavior or help you do it.

Maybe this could be helpful, though:

http://cheeseshop.python.org/pypi/workingenv.py

make testing environment, and away you go. Probably good for testing different combinations of of separate packages too. (MPL 0.7 and 0.9 with wxPython2.6 and 2.8, for instance)

Very nice! It would actually be really cool if we could integrate this (or something like it) with either the test releases or wxPython itself. i.e. you could go into the root of a pre-release and run ./test_wxPython.py(w) and it would setup the testing environment for you and then run the demo. Then the user could still have the isolation, and not have to do anything to get it.

Regards,

Kevin

···

On May 25, 2007, at 11:10 AM, Christopher Barker wrote:

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org