gmane.comp.python.enthought.devel

bryce hendrix | 18 Jul 18:11

Re: Overview of ETS 3.0 tests

Ilan, I tried running the BlockCanvas integration tests, and there is 
something strange going on with the import in 
integrationtests/numeric_context/numeric_context_test_case.py. If I run 
the file manually, all tests pass, but if ran from within nose a local 
import fails. I ran all of the integration tests, which I found 2 errors 
and 2 failures.

Any idea what nose is doing that breaks the import?

Bryce

Ilan Schnell wrote:
> Hi,
> I've complied an overview of the different projects and the failure
> rates:
> http://www.enthought.com/~ischnell/ets.txt
>
> The first number is always the number of tests run in that folder.
> I would say that things are not so bad:
> - BlockCanvas has the most failures, many things are out of data
> - Traits needs some more work.
> - Mayavi basically passes the tests, but they are not really meant
>   to be run by nosetests
>
> - Ilan
>
> _______________________________________________
> Enthought-dev mailing list
> Enthought-dev@...
> https://mail.enthought.com/mailman/listinfo/enthought-dev

(Continue reading)

headers

Ilan Schnell | 18 Jul 18:29

Re: Overview of ETS 3.0 tests

Bryce, yes, I've had this problem with other tests as well, so I fixed the
imports in such a way that nose finds them, e.g.:
https://svn.enthought.com/enthought/changeset/20042
It is strange that nose is not able to find simple local imports, even when
you run it in the same directory.  On the other hand nose is trying to do
so many other "clever" things that it was necessary to run it as a
subprocess
in the according test directory.  Let's hope future versions of nose fix
these
issues, but for now we have to deal with it.

- Ilan

bryce hendrix wrote:
> Ilan, I tried running the BlockCanvas integration tests, and there is 
> something strange going on with the import in 
> integrationtests/numeric_context/numeric_context_test_case.py. If I run 
> the file manually, all tests pass, but if ran from within nose a local 
> import fails. I ran all of the integration tests, which I found 2 errors 
> and 2 failures.
>
> Any idea what nose is doing that breaks the import?
>
> Bryce
>
> Ilan Schnell wrote:
>   
>> Hi,
>> I've complied an overview of the different projects and the failure
>> rates:

(Continue reading)

headers

Robert Kern | 18 Jul 20:17

Re: Overview of ETS 3.0 tests

On Fri, Jul 18, 2008 at 11:29, Ilan Schnell <ischnell@...> wrote:
> Bryce, yes, I've had this problem with other tests as well, so I fixed the
> imports in such a way that nose finds them, e.g.:
> https://svn.enthought.com/enthought/changeset/20042
> It is strange that nose is not able to find simple local imports, even when
> you run it in the same directory.  On the other hand nose is trying to do
> so many other "clever" things that it was necessary to run it as a
> subprocess
> in the according test directory.  Let's hope future versions of nose fix
> these
> issues, but for now we have to deal with it.

I don't know about that. I reverted that change, and that test file
worked fine when running from any directory. Same with the
BlockCanvas/integrationtests/. I'm using nose 0.10.3 on OS X and
Ubuntu, at least.

One alternative to test_all.py is simply to explicitly specify the
test directories in the setup.cfg. For example, for Mayavi

  [nosetests]
  tests=tests/,enthought/tvtk/tests/

Note that the _port_ directories under BlockCanvas should be omitted.
They contain nonessential things that still refer to the geo package
or otherwise need to be updated. Most of the remaining
BlockCanvas/integrationtests/ failures stem from the fact that it
simply hasn't been ported to use nose, yet. It does custom collection
for unittest. Anyways, the numeric_context code it's testing is
obsolete, so it's not really important.

(Continue reading)

headers

Prabhu Ramachandran | 19 Jul 20:47

Re: Overview of ETS 3.0 tests

Ilan Schnell wrote:
> Hi,
> I've complied an overview of the different projects and the failure
> rates:
> http://www.enthought.com/~ischnell/ets.txt
> 
> The first number is always the number of tests run in that folder.
> I would say that things are not so bad:
> - BlockCanvas has the most failures, many things are out of data
> - Traits needs some more work.
> - Mayavi basically passes the tests, but they are not really meant
>   to be run by nosetests

Thanks for this.  I've reorganized the mayavi tests quite a bit and 
test_all.py no longer picks up the mayavi integration tests.  I have 
however fixed various test related issues so more of them ought to pass.

The mayavi tests do not play nicely with nose.  I think this can be 
fixed and have something that works for one of the tests in my working copy.

There is one major issue I do have though.  It is possible to run the 
tests with different command line options

$ python test_image_plane_widget.py -h
Usage: test_image_plane_widget.py [options]

Options:
   -h, --help        show this help message and exit
   -v, --verbose     Print verbose output
   -i, --interact    Allow interaction after test (default: False)

(Continue reading)

headers

Ilan Schnell | 19 Jul 23:58

Re: Overview of ETS 3.0 tests

Hi Prabhu,
The reason why test_all.py does not pick up the integration tests
is because nose does not pick them up.  test_all.py just runs nose
in integrationtests as a subprocess.  If I go to integrationtests and
run nose manually nothing happens either (at least with nose 0.10.3).
Different version of nose behave differently, and its causing a lot of
trouble, but essentially test_all.py can do whatever it wants.  For
example to run the command line options you can say something like
  retval = subprocess.call(['python', 'test_image_plane_widget.py', '-h'])
  ...
  self.assertEqual(retval, 0)
test_all.py should however run all the test suites, i.e. if one fails
the others should still run and at the end it prints out a summary before
checking if all went well.  Note also that test_all needs to be a unittest,
such that it works when you say: python setup.py test

I assume that:
./enthought/mayavi/tests   are more "internal" tests
./integrationtests         are graphical tests

If this is true, I will move test_csv_sniff.py and the corresponding folder
with test files to ./enthought/mayavi/tests

I hope you had a god trip back to India.

- Ilan

Prabhu Ramachandran wrote:
> Ilan Schnell wrote:
>

(Continue reading)

headers

Robert Kern | 20 Jul 00:07

Re: Overview of ETS 3.0 tests

On Sat, Jul 19, 2008 at 16:58, Ilan Schnell <ischnell@...> wrote:
> Hi Prabhu,
> The reason why test_all.py does not pick up the integration tests
> is because nose does not pick them up.  test_all.py just runs nose
> in integrationtests as a subprocess.

Note that things in integrationtests/ directories are not supposed to
be part of the main test suite. "python setup.py test" should not run
them. It is a place for tests that need to be manually run for visual
verification or take very long or other such things that should not be
automated.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco

headers

Ilan Schnell | 20 Jul 00:14

Re: Overview of ETS 3.0 tests

Thanks Robert, this is important for me to know.  This means that
test_all.py
should not run anything in integrationtests either.

Robert Kern wrote:
> On Sat, Jul 19, 2008 at 16:58, Ilan Schnell <ischnell@...> wrote:
>   
>> Hi Prabhu,
>> The reason why test_all.py does not pick up the integration tests
>> is because nose does not pick them up.  test_all.py just runs nose
>> in integrationtests as a subprocess.
>>     
>
> Note that things in integrationtests/ directories are not supposed to
> be part of the main test suite. "python setup.py test" should not run
> them. It is a place for tests that need to be manually run for visual
> verification or take very long or other such things that should not be
> automated.
>
>

headers

Robert Kern | 20 Jul 00:22

Re: Overview of ETS 3.0 tests

On Sat, Jul 19, 2008 at 17:14, Ilan Schnell <ischnell@...> wrote:
> Thanks Robert, this is important for me to know.  This means that
> test_all.py
> should not run anything in integrationtests either.

Yes. However, I do recommend using the setup.cfg approach instead of
test_all.py. It allows users to just run nosetests with whatever
commandline options they need (e.g. --pdb, --with-coverage, etc.).

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco

headers

Ilan Schnell | 20 Jul 01:44

Re: Overview of ETS 3.0 tests

Yes, I agree.  Using the tests option in setup.cfg things work with
both nose 0.9.3 and 0.10.3, however now if somebody adds new tests,
the list needs to be updated.  I think I will try to use the standard
setup.cfg approach when possible, and only fall back on test_all.py
when things need a more specific solution.

Robert Kern wrote:
> On Sat, Jul 19, 2008 at 17:14, Ilan Schnell <ischnell@...> wrote:
>   
>> Thanks Robert, this is important for me to know.  This means that
>> test_all.py
>> should not run anything in integrationtests either.
>>     
>
> Yes. However, I do recommend using the setup.cfg approach instead of
> test_all.py. It allows users to just run nosetests with whatever
> commandline options they need (e.g. --pdb, --with-coverage, etc.).
>
>

headers

Prabhu Ramachandran | 20 Jul 04:59

Re: Overview of ETS 3.0 tests

Robert Kern wrote:
> On Sat, Jul 19, 2008 at 16:58, Ilan Schnell <ischnell@...> wrote:
>> Hi Prabhu,
>> The reason why test_all.py does not pick up the integration tests
>> is because nose does not pick them up.  test_all.py just runs nose
>> in integrationtests as a subprocess.
> 
> Note that things in integrationtests/ directories are not supposed to
> be part of the main test suite. "python setup.py test" should not run
> them. It is a place for tests that need to be manually run for visual
> verification or take very long or other such things that should not be
> automated.

In the strict sense of the term, most of the mayavi2 tests are 
integration tests.  They do however test various modules/filters and I 
see no reason why they shouldn't be automated.  The tests do take a 
while with about 20 of them each taking about 10 seconds.  There isn't 
any visual verification required.  There is one image based test but 
that does not need user intervention either.

So I am unsure what exactly I am to do about these tests.  I can make 
them play nicely with nose which I will do.  However, as it stands, the 
tests also support command line arguments which sometimes conflict with 
nosetests' command line options.

I also have code (run.py) to run these faster by running them all in one 
go rather than individually but that isn't important and can be removed.

I'd like to fix these so the tests are easier to run and follow standard 
operating procedures.  Can you comment on what I need to do.

(Continue reading)

headers

Prabhu Ramachandran | 20 Jul 06:06

Re: Overview of ETS 3.0 tests

Prabhu Ramachandran wrote:
> Right now I am inclined to just make them play nicely with nosetests so 
> you can run nosetests in the directory and it runs all the tests.  If 
> people need to run it with certain command line options they may do so 
> either as python [options] test_something.py or as nosetests [args] 
> where the args may be re-interpreted by the test (for example -s will 
> run the test standalone but is also nosetests option to not capture stdout).

I've just checked in this.  So now, the tests should run with nosetests. 
  You can do:

  cd integrationtests/mayavi
  nosetests

and it should run everything.  Run:

  nosetests -s

to run them standalone.  It won't support offscreen (-so) since 
nosetests doesn't have a -o option.

cheers,
prabhu

headers

Ilan Schnell | 21 Jul 04:41

Re: Overview of ETS 3.0 tests

Hi,
thanks for all the hard work Prabhu.  I can integrationtests/mayavi
with the run.py but when I use nosetests -s I get a wx error in one
of the later tests.  I'm not really sure if it's a good idea to
include the integrationtests in test_all.  Anyway, the reason
I started writing the test_all.py scripts was because of
a bug/feature in nose 0.10.3.  With that version it is not possible
to run nose in the root of a project (because I gets confused by with
the package namespaces), however it is possible to run nose 0.10.3 in
each directory by itself.  Also if one adds the line
  tests = enthought/tvtk/tests,enthought/mayavi/tests
to the nosetests section in setup.cfg things work (with 0.10.3),
whereas the shell command
  Mayavi_3.0.0a1$ nosetests enthought/tvtk/tests enthought/mayavi/tests
fails (which as fas as I understand does the same thing).

Regardless of the integrationtests, the other tests all work fine,
except that, enthought/tvtk/tests/test_tvtk.py only work with python
and nose 0.9.3, when I run it with nose 0.10.3 I get an AssertionError
in line 190 but I don't know what going on in detail.

- Ilan

Prabhu Ramachandran wrote:
> Prabhu Ramachandran wrote:
>   
>> Right now I am inclined to just make them play nicely with nosetests so 
>> you can run nosetests in the directory and it runs all the tests.  If 
>> people need to run it with certain command line options they may do so 
>> either as python [options] test_something.py or as nosetests [args]

(Continue reading)

headers

Prabhu Ramachandran | 21 Jul 15:04

Re: Overview of ETS 3.0 tests

Ilan Schnell wrote:
> thanks for all the hard work Prabhu.  I can integrationtests/mayavi

Thanks!  It took a long while to get everything working.

> with the run.py but when I use nosetests -s I get a wx error in one
> of the later tests.  I'm not really sure if it's a good idea to

I've fixed many things so the tests work (so make sure your checkout is 
up-to-date); just run nosetests (don't specify -s).  The tests work on 
the Mac and under Linux.  The test_streamline one may fail with an image 
error but I'll work around that later.  However, with nose-0.10.3 things 
ought to work.  Please send me errors you get.  I won't get to them 
before the weekend though.

> include the integrationtests in test_all.  Anyway, the reason
> I started writing the test_all.py scripts was because of
> a bug/feature in nose 0.10.3.  With that version it is not possible
> to run nose in the root of a project (because I gets confused by with
> the package namespaces), however it is possible to run nose 0.10.3 in
> each directory by itself.  Also if one adds the line
>   tests = enthought/tvtk/tests,enthought/mayavi/tests
> to the nosetests section in setup.cfg things work (with 0.10.3),
> whereas the shell command
>   Mayavi_3.0.0a1$ nosetests enthought/tvtk/tests enthought/mayavi/tests
> fails (which as fas as I understand does the same thing).

This is very wierd.  I get an error that looks like a reload of a module 
happened which causes wierd errors.

(Continue reading)

headers

Ilan Schnell | 22 Jul 02:43

Re: Overview of ETS 3.0 tests

Hi Prabhu,
can you take a look at revison 20153.  I don't know why it is
failing when invoked via python setup.py test:
Traceback (most recent call last):
  File
"/home/ischnell/ets/ETS_3.0.0b1/Mayavi_3.0.0a1/enthought/mayavi/tests/test_pipeline_info.py",
line 24, in test_tvtk_dataset_name
    datasets = [tvtk.ImageData(),
  File "tvtk_classes/image_data.py", line 32, in __init__
    tvtk_base.TVTKBase.__init__(self, vtk.vtkImageData, obj, update,
**traits)
TypeError: unbound method __init__() must be called with TVTKBase
instance as first argument (got ImageData instance instead)

However, from enthought.tvtk.api import tvtk work, but then something
goes wrong.

Thanks  Ilan

Prabhu Ramachandran wrote:
> Robert Kern wrote:
>   
>> On Sat, Jul 19, 2008 at 16:58, Ilan Schnell <ischnell@...> wrote:
>>     
>>> Hi Prabhu,
>>> The reason why test_all.py does not pick up the integration tests
>>> is because nose does not pick them up.  test_all.py just runs nose
>>> in integrationtests as a subprocess.
>>>       
>> Note that things in integrationtests/ directories are not supposed to

(Continue reading)

headers

Prabhu Ramachandran | 22 Jul 04:20

Re: Overview of ETS 3.0 tests

Ilan Schnell wrote:
> Hi Prabhu,
> can you take a look at revison 20153.  I don't know why it is
> failing when invoked via python setup.py test:
> Traceback (most recent call last):
>   File
> "/home/ischnell/ets/ETS_3.0.0b1/Mayavi_3.0.0a1/enthought/mayavi/tests/test_pipeline_info.py",
> line 24, in test_tvtk_dataset_name
>     datasets = [tvtk.ImageData(),
>   File "tvtk_classes/image_data.py", line 32, in __init__
>     tvtk_base.TVTKBase.__init__(self, vtk.vtkImageData, obj, update,
> **traits)
> TypeError: unbound method __init__() must be called with TVTKBase
> instance as first argument (got ImageData instance instead)
> 
> However, from enthought.tvtk.api import tvtk work, but then something
> goes wrong.

Well, I have no idea.  I was getting these when I ran nosetests 
enthought/mayavi/tests enthought/tvtk/tests
and combinations of the above.  However, this is completely 
non-reproducible.  Right now, with python setup.py test, everything 
except one test passes -- here is the output:

[...]
ok
Failure: ImportError (No module named test_support) ... ERROR
Is the default PipelineInfo class built right. ... ok
test_tvtk_dataset_name 
(enthought.mayavi.tests.test_pipeline_info.TestPipelineInfoTest) ... ok

(Continue reading)

headers

Ilan Schnell | 22 Jul 14:24

Re: Overview of ETS 3.0 tests

Prabhu,
hmm, why are you getting the ImportError for test.test_support?
This is in the standard Python Library, maybe it is an unfortunate
name collision on your system.  I'll check this (and other things)
on other machines and environments, maybe that will give us a clue.

- Ilan

Prabhu Ramachandran wrote:
> Ilan Schnell wrote:
>   
>> Hi Prabhu,
>> can you take a look at revison 20153.  I don't know why it is
>> failing when invoked via python setup.py test:
>> Traceback (most recent call last):
>>   File
>> "/home/ischnell/ets/ETS_3.0.0b1/Mayavi_3.0.0a1/enthought/mayavi/tests/test_pipeline_info.py",
>> line 24, in test_tvtk_dataset_name
>>     datasets = [tvtk.ImageData(),
>>   File "tvtk_classes/image_data.py", line 32, in __init__
>>     tvtk_base.TVTKBase.__init__(self, vtk.vtkImageData, obj, update,
>> **traits)
>> TypeError: unbound method __init__() must be called with TVTKBase
>> instance as first argument (got ImageData instance instead)
>>
>> However, from enthought.tvtk.api import tvtk work, but then something
>> goes wrong.
>>     
>
> Well, I have no idea.  I was getting these when I ran nosetests

(Continue reading)

headers

Prabhu Ramachandran | 22 Jul 17:22

Re: Overview of ETS 3.0 tests

Ilan Schnell wrote:
> Prabhu,
> hmm, why are you getting the ImportError for test.test_support?
> This is in the standard Python Library, maybe it is an unfortunate
> name collision on your system.  I'll check this (and other things)
> on other machines and environments, maybe that will give us a clue.

Indeed it was a name collision.  I had another test.py in my path.

Now I get
Ran 112 tests in 33.689s
OK.

So all is good.  It would be nice though if others could just run 
nosetests on the integrationtests/mayavi and see how it goes.  Thanks.

prabhu

headers

Gael Varoquaux | 23 Jul 09:14

Re: Overview of ETS 3.0 tests

On Tue, Jul 22, 2008 at 08:52:47PM +0530, Prabhu Ramachandran wrote:
> Now I get
> Ran 112 tests in 33.689s
> OK.

Great. All we need is a cron job to do that, and add this to the dash
board :).

> So all is good.  It would be nice though if others could just run 
> nosetests on the integrationtests/mayavi and see how it goes.  Thanks.

Not one error, not one failure! And not one window poping up. We can
really run this on a box in a daily, or even hourly, basis. This is huge
progress. Thanks a lot to everybody involved. This will also be pushing
me to write more tests.

Gaël

headers

Prabhu Ramachandran | 23 Jul 14:12

Re: Overview of ETS 3.0 tests

Gael Varoquaux wrote:
> On Tue, Jul 22, 2008 at 08:52:47PM +0530, Prabhu Ramachandran wrote:
>> Now I get
>> Ran 112 tests in 33.689s
>> OK.
> 
> Great. All we need is a cron job to do that, and add this to the dash
> board :).
> 
>> So all is good.  It would be nice though if others could just run 
>> nosetests on the integrationtests/mayavi and see how it goes.  Thanks.
> 
> Not one error, not one failure! And not one window poping up. We can
> really run this on a box in a daily, or even hourly, basis. This is huge
> progress. Thanks a lot to everybody involved. This will also be pushing
> me to write more tests.

Well, one tests has problems thanks to nosetests vagaries and that is 
unfortunately "skipped".  In addition, I don't think you must have run 
the tests in integrationtests -- they don't run on python setup.py test 
and they should pop up windows.  So maybe those never ran!

regards,
prabhu

headers

Prabhu Ramachandran | 20 Jul 05:09

Re: Overview of ETS 3.0 tests

Hi Ilan,

Ilan Schnell wrote:
> The reason why test_all.py does not pick up the integration tests
> is because nose does not pick them up.  test_all.py just runs nose
> in integrationtests as a subprocess.  If I go to integrationtests and
> run nose manually nothing happens either (at least with nose 0.10.3).
> Different version of nose behave differently, and its causing a lot of
> trouble, but essentially test_all.py can do whatever it wants.  For
> example to run the command line options you can say something like
>   retval = subprocess.call(['python', 'test_image_plane_widget.py', '-h'])
>   ...
>   self.assertEqual(retval, 0)
> test_all.py should however run all the test suites, i.e. if one fails

Well, you do look for certain directories in the test_directories method 
and I think it may be easier to modify that to do the job rather than 
explicitly list each file.  Perhaps adding the ability to specify a list 
of relative paths of directories to run nose in would make this convenient.

> the others should still run and at the end it prints out a summary before
> checking if all went well.  Note also that test_all needs to be a unittest,
> such that it works when you say: python setup.py test

I thought python setup.py test would work with nose if you use 
nose.collector in setup.py?

> I assume that:
> ./enthought/mayavi/tests   are more "internal" tests
> ./integrationtests         are graphical tests

(Continue reading)

headers

Martin Chilvers | 21 Jul 09:00

Re: Overview of ETS 3.0 tests

Hi Ilan,

I'm still curious about the skipped test in EnvisageCore... It works for me, so we need to work out 
why it doesn't work over there... There should be no reason to skip any tests in Envisage...

Good job with the tests BTW! Can we publish coverage numbers too?

Martin

headers

Ilan Schnell | 21 Jul 16:35

Re: Overview of ETS 3.0 tests

Hi Martin,

this is the error I get when a remove the line which skips the test:

Traceback (most recent call last):
  File "provider_extension_registry_test_case.py", line 478, in
test_remove_provider
    self.assertEqual('x', listener.extension_point)
AssertionError: 'x' !=
<enthought.envisage.extension_point.ExtensionPoint object at 0x850fe4c>

The tests
  self.assertEqual('x', listener.extension_point)
  self.assertEqual([], listener.added)
  self.assertEqual([42], listener.removed)
fail on my system, thats why I decided to skip them for now (see FIXME).

Currently, I'm not worried about publishing coverage numbers,
the goal right now is to get all tests working for the
upcoming ETS 3.0 release.

- Ilan

Martin Chilvers wrote:
> Hi Ilan,
>
> I'm still curious about the skipped test in EnvisageCore... It works for me, so we need to work out 
> why it doesn't work over there... There should be no reason to skip any tests in Envisage...
>
> Good job with the tests BTW! Can we publish coverage numbers too?

(Continue reading)

headers

Martin Chilvers | 21 Jul 17:52

Re: Overview of ETS 3.0 tests

Ilan Schnell wrote:
> Hi Martin,
> 
> this is the error I get when a remove the line which skips the test:
> 
> Traceback (most recent call last):
>   File "provider_extension_registry_test_case.py", line 478, in
> test_remove_provider
>     self.assertEqual('x', listener.extension_point)
> AssertionError: 'x' !=
> <enthought.envisage.extension_point.ExtensionPoint object at 0x850fe4c>
> 
> The tests
>   self.assertEqual('x', listener.extension_point)
>   self.assertEqual([], listener.added)
>   self.assertEqual([42], listener.removed)
> fail on my system, thats why I decided to skip them for now (see FIXME).

Hmmmm, what version of traits are you using? I am usingv the latest trunk revision (20059)...

Also, how do you invoke the tests?

Martin

headers

Ilan Schnell | 21 Jul 18:11

Re: Overview of ETS 3.0 tests

I ivoke this test simply by:
-> pwd
/home/ischnell/ets/ETS_3.0.0b1/EnvisageCore_3.0.0b1/enthought/envisage/tests
-> python provider_extension_registry_test_case.py
..........No handlers could be found for logger
"enthought.envisage.provider_extension_registry"
..........F.
======================================================================
FAIL: remove provider
----------------------------------------------------------------------
Traceback (most recent call last):
  File "provider_extension_registry_test_case.py", line 478, in
test_remove_provider
    self.assertEqual('x', listener.extension_point)
AssertionError: 'x' !=
<enthought.envisage.extension_point.ExtensionPoint object at 0x8510e2c>

----------------------------------------------------------------------
Ran 22 tests in 0.023s

The Trais version I use it the current trunk (revision 20105).

- Ilan

Martin Chilvers wrote:
> Ilan Schnell wrote:
>   
>> Hi Martin,
>>
>> this is the error I get when a remove the line which skips the test:

(Continue reading)

headers

Martin Chilvers | 21 Jul 18:51

Re: Overview of ETS 3.0 tests

Hi Ilan,

> Traceback (most recent call last):
>   File "provider_extension_registry_test_case.py", line 478, in
> test_remove_provider
>     self.assertEqual('x', listener.extension_point)
> AssertionError: 'x' !=
> <enthought.envisage.extension_point.ExtensionPoint object at 0x8510e2c>

As it turns out, there *is* a bug in the provider extension registry and it was passing the 
extension point to its listeners instead of the extension point Id...

Before I check in the fix tho', I want to work out why it passed for me! What else could be 
different between our setups? Are you using Python 2.4 or 2.5? No idea why that should matter, but 
hey...

Martin

headers

Ilan Schnell | 21 Jul 20:52

Re: Overview of ETS 3.0 tests

Hi Martin,

I use:
Python 2.5.1 (r251:54863, Sep 22 2007, 01:43:31)
[GCC 4.2.1 (SUSE Linux)] on linux2

Martin Chilvers wrote:
> Hi Ilan,
>
>   
>> Traceback (most recent call last):
>>   File "provider_extension_registry_test_case.py", line 478, in
>> test_remove_provider
>>     self.assertEqual('x', listener.extension_point)
>> AssertionError: 'x' !=
>> <enthought.envisage.extension_point.ExtensionPoint object at 0x8510e2c>
>>     
>
> As it turns out, there *is* a bug in the provider extension registry and it was passing the 
> extension point to its listeners instead of the extension point Id...
>
> Before I check in the fix tho', I want to work out why it passed for me! What else could be 
> different between our setups? Are you using Python 2.4 or 2.5? No idea why that should matter, but 
> hey...
>
> Martin
>
> _______________________________________________
> Enthought-dev mailing list
> Enthought-dev@...

(Continue reading)

headers

Martin Chilvers | 22 Jul 10:41

Re: Overview of ETS 3.0 tests

Ilan Schnell wrote:
> Hi Martin,
> 
> I use:
> Python 2.5.1 (r251:54863, Sep 22 2007, 01:43:31)
> [GCC 4.2.1 (SUSE Linux)] on linux2

Hmmmmmm, my guess is that it is down to a change in the hashing algorithm in Python... (sounds a bit 
obtuse, but thats my guess!)... The reason is that, there was a bug in the test as it assumed only 
one event would be fired when in fact there were 3 (there should have only been two, but that was 
the *actual* bug!)... The events were built up in a dictionary which we then iterated over with 
'.items()'... On my machine with Python 2.4, the 'x' event came last hence the event passed... My 
guess is that one your machine with Python 2.5, the broken/duplicste event came last...

Martin