Unit testing

[Andre Roberge]

Hi everyone,

When I wrote rur-ple, I had no concept of unit testing; I was just having fun learning to program in Python and seeing that things worked properly by running the program and testing it like any end-user would.

I think it would be very useful if we were to change this.

I would like to suggest that from now on, each time we fix a bug, we write a test for it. Before we do this though, we should agree on some unit testing framework. Based on the recent pattern, it appears likely that many of you will write more code for rur-ple than I will.  Therefore, I don't think I should be the one to decide which testing framework should be used.

Feel free to comment on this! :-)

André

[Frederic Muller]

That sounds like a good idea. I have no experience with any testing
framework though (and I doubt I will write more python code that you
will considering my lack of knowledge in that language... but that's
another story).

Anything you feel familiar with and suitable will work for me.

Thanks
Fred

> Andr�

[Frederic Muller]

So replying again to this thread as now we have a few key points to test
over 2 different versions of wxpython (making it easy to miss
something). my only experience is with manual QA 'scripts' using TCW (an
opensource tools which just saves the scenario and records whether it
was a pass or a fail).
Benefits: you don't forget anything and very simple interface

We currently have the following matrix:
wxPython 2.6 wxPython 2.8
source
Linux
Windows
Mac
Binary
Linux
Windows
Mac

The points to be tested based on previous bugs are:
- language switching
- arrow keys
- speed slider
- world loading
- world refresh
- help in simple editor
- launching from command line
- launching from menu

and we can probably add a bit more where we didn't have any bug but they
could appear.

Then next release extra tests (due to new features or new behavior)
- load/save code, world and simple editor files
- UI display in different startup sizes (font differences might generate
scrollbars)

Do you see anything to add and how do we proceed?

Also I noticed some code has been written for wxPython 2.4, shall we
also try to support that version?

I do have some spare hosting space for us to host stuff if necessary.

Fred
ps: i already sent that email but it apparently never reached the list.

[Peter Maas]

On 17 Jan., 06:48, Frederic Muller <f...@beijinglug.org> wrote:
> We currently have the following matrix:
> wxPython 2.6 wxPython 2.8
> source
> Linux
> Windows
> Mac
> Binary
> Linux
> Windows
> Mac
>

Hi,

this matrix refers to regression tests which are to verify the built
and deployed software. A unit test is to verify a single code unit so
that the developer can detect failures after a code change.

The Python standard library has some test modules:

- doctest (test single function based on interpreter response)
- unittest (test single class or module)
- test (regression test)

I suggest to start with these. A doctest can be part of a unittest
which can be part of a regression test. Testing GUIs is notoriously
difficult to automate. A first step to make this easier would be to
separate application logic from wxPython code. Unit tests work best on
coherent units with well defined interfaces. So I think that some
further refactoring of the code base is advisable to make good use of
unit tests.

> Also I noticed some code has been written for wxPython 2.4, shall we
> also try to support that version?

wxPython 2.4 is 7 years old. There was a transition from wx as a name
prefix to wx as a package during or after the 2.4 release with
considerable changes in the code base. So I advise strongly against
2.4 compatibility. I think we all work on rur-ple for fun in our spare
time. Supporting many trivial variations of the same stuff for
compatibility is not very funny :)

Regards, Peter

(Testing unicode, please ignore: <äöüß所有網頁>)

[Frederic Muller]

Thanks for clarifying. I am not much of a developer (last lines of code
I wrote were in Turbo Pascal in the early 90's). Then considering the
work involved we could wait for v2.0 (I understood it needed
rewriting...)? I will still try to read a bit more about those test
modules you're referring to, can't be bad for me anyway...

Regarding python 2.4 support I have no idea about the work involved. In
fact I just see that every other version of wxPython breaks backward
compatibility and is therefore a pain to maintain. My only concern is
about supporting old hardware. I work a lot with either slow or recycled
PCs and sometimes only Win'98 runs well on it (quite rare though). We're
talking in general Pentium III @ 500MHZ with 256MB of ram. So maybe I
should rephrase my concerns with the following question:
what's the minimum requirement for wxPython and Python to get RUR-PLE
running on this kind of hardware?

Thanks a lot.

Fred

[Peter Maas]

On 18 Jan., 03:51, Frederic Muller <f...@beijinglug.org> wrote:
> Regarding python 2.4 support I have no idea about the work involved. In
> fact I just see that every other version of wxPython breaks backward
> compatibility and is therefore a pain to maintain.

You are right. But the aforementioned prefix-to-namespace transition
was
a really deep cut. We could write the GUI twice to support it or write
a
very thick compatibilty layer.

> My only concern is
> about supporting old hardware. I work a lot with either slow or recycled
> PCs and sometimes only Win'98 runs well on it (quite rare though). We're
> talking in general Pentium III @ 500MHZ with 256MB of ram. So maybe I
> should rephrase my concerns with the following question:
> what's the minimum requirement for wxPython and Python to get RUR-PLE
> running on this kind of hardware?

I don't have the hardware to really answer your question exactly :)
but running
rur-ple shouldn't be a problem on the system you mentioned. My weakest
Computer is a Pentium III @ 800 MHz witz 512 MB RAM. I don't observe
even the
tiniest problem. rur-ple with wxPython 2.6 uses 30 MB right after the
start.
Building a list of 1 million integers adds 7 MB. So there's really no
need to support
wxPython 2.4.

Regards, Peter.

Peter Maas, Aachen, Germany

[Sun Liwen]

2010/1/19 Peter Maas <fritz.pe...@googlemail.com>

Hi, 

2010/1/18 Frederic Muller <fr...@beijinglug.org>

Thanks for clarifying. I am not much of a developer (last lines of code I wrote were in Turbo Pascal in the early 90's).  Then considering the work involved we could wait for v2.0 (I understood it needed rewriting...)? I will still try to read a bit more about those test modules you're referring to, can't be bad for me anyway...

Regarding python 2.4 support I have no idea about the work involved. In fact I just see that every other version of wxPython breaks backward compatibility and is therefore a pain to maintain. My only concern is about supporting old hardware. I work a lot with either slow or recycled PCs and sometimes only Win'98 runs well on it (quite rare though). We're talking in general Pentium III @ 500MHZ with 256MB of ram. So maybe I should rephrase my concerns with the following question:

what's the minimum requirement for wxPython and Python to get RUR-PLE running on this kind of hardware?

Hi,

We have some very old IBM workstations running PIII 500MHz & Windows 2000.

RUR-PLE is running well on them. 

IMO, I don't think we have much need of multiple versions support.

Maybe we can choose a most commonly accepted version of python and wxpython. 

In which way we can reduce the time to test. 

--
Yours,
Sun Liwen
+ 86 13810111838

[Frederic Muller]

So replying again to this thread as now we have a few key points to test
over 2 different versions of wxpython (making it easy to miss
something). my only experience is with manual QA scripts using TCW (an
opensource tools which just saves the scenario and records whether it

was a pass or a fail.

Benefits: you don't forget anything and very simple interface

We currently have the following matrix:

wxPython 2.6 wxPython 2.8
source
Linux
Windows
Mac
Binary
Linux
Windows
Mac

The points to be tested based on previous bugs are:

- language switching
- arrow keys
- speed slider
- world loading
- world refresh
- help in simple editor
- launching from command line
- launching from menu

and we can probably add a bit more where we didn't have any bug but they
could appear.

Then next release extra tests (due to new features or new behavior)

load/save code, world and simple editor files.

Do you see anything to add and how do we proceed?

I do have some spare hosting space for us to host stuff if necessary.

Fred