Gary S. Thompson wrote:
Edward d'Auvergne wrote:
On 3/16/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Edward d'Auvergne wrote:
>> On 3/15/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
>> > Edward d'Auvergne wrote:
>> >
>> > > Hi,
>> > >
>> > > Thank you very much for your efforts. The unit test
framework is
>> > > running very smoothly. There are two features or points which I
>> could
>> > > handle if you would like. The first is the addition of cross
>> platform
>> > > compatibility with paths, directory separators, etc. This I
>> should be
>> > > able to fix up quickly.
>> >
>> > I will try a run on my windows box at home at some point
>
>
> I can make the modifications if you like. After reading
> http://docs.python.org/lib/os-path.html I noticed that even the
> current directory '.' is not a constant, in Mac OS 9 it is actually
> the colon ':'!
go ahead an i will have a look at the diffs and see if I cans
seeanything else
I'll get to it tomorrow.
(nb is there a side by side diff untility for svn?)
Not that I'm aware of. There may be a tool to convert the universal
diff to other diff formats. Alternatively the webcvs frontend to the
svn repository will give you something similar to side-by-side diff
and it is colour coded as well.
regards
gary
n.b. there is at least one place where '.' is used as an implicit
constant and not put into a path
n.b. it might be a good idea if the unix syntax always works if
possible
because that allows cross platform compatability. note support for unix
pathes is a part of the python paradigm
If '.' is translated into the value of 'os.curdir', then this could be
supported. Ideally a function to determine if the supplied path is
'posix', 'nt', 'os2', 'mac', 'ce' or 'riscos' could be created. It's
return value would be the path in the format recognised by the
executing operating system.
Alternatively the ad hoc user of Unit_test_runner can supply a non
platform independent string and it should just operate fine on their
system (Python by default operates this way). A script the user
creates in this way would not be cross platform compatible. relax
however would use 'os.curdir', 'os.pardir', and 'os.sep' and
internally will be platform independent.
this is the right way to go
cf
*normpath*( path)
Normalize a pathname. This collapses redundant separators and
up-level references so that |A//B|, |A/./B| and |A/foo/../B| all
become |A/B|. It does not normalize the case (use normcase() for
that). On Windows, it converts forward slashes to backward slashes.
It should be understood that this may change the meaning of the
path
if it contains symbolic links!
as an example
Does this convert any OS path format to the current OS? Do you know
if it converts 'posix' paths to the format of the executing operating
system (rather than just converting to Windows directory separators
when required)? If so, this would be the best solution.
I believe it works on all platforms (n.b. the mac case I think only
applies to the case where the mac is an old one running a pre os x
operating system and the likley hood of anyone doing much productive
work there with relax is low)
> I've already done a lot of this portability stuff in
> the rest of relax so I can quickly go through and make all necessary
> changes.
>
>
>> > > The second may take a small redesign of the
>> > > code for searching for unit tests. At the moment there appears
>> to be
>> > > no technique for running unit tests for functions or class
methods
>> > > located within the relax '__init__.py' files. For example in
the
>> > > current revision of the 1.3 line (r3199), there is the file
>> > > 'test_suite/unit_tests/data/test___init__.py' which contains
unit
>> > > tests for the class methods of the relax data storage singleton
>> in the
>> > > relax file 'data/__init__.py'. If you like, I could have a
go at
>> > > fixing this.
>> > >
>> > Hum interesting I will need to think about this. If you can see a
>> simple
>> > solution go for it and I can have a look at the results otherwise
>> Imore
>> > will think about it soon (next 2-3 days)
>
>
I have analysed the problem here and there are two things
1. the test case for a file called test___init__.py is currently
assumed
to be the class Test___init__(TestCase)
That'll be the problem! Thanks. What do you think of the idea of
extending the searching capabilities to find all classes starting with
'Test_' (or alternatively those subclassed from TestCase)? The module
could then reflect the setup of relax modules containing multiple
classes - each relax module class has a corresponding unit test
TestCase class.
This is nice and simple for the momemnt I don't see a need for
scanning a module for all classes, we just need to fix the module
problem?
However, maybe it isn't so bad!
# junk.py
class foo:pass
class bar(foo):pass
Then:
>>> import junk
>>> import inspect
>>> test = inspect.getmembers(junk, inspect.isclass)
>>> print test
[('bar', <class 'junk.bar'>), ('foo', <class junk.foo at 0x10102d28>)]
>>>issubclass(test[0],test[1])
True
also test[0].__name__
'bar'
etc
[snip] already answered
...
Cheers,
Edward
.
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
Re: [Fwd: Re: r3194 - in /1.3: relax test_suite/runner.py test_suite/unit_tests/unit_test_runner.py]