[Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py

[Walter Dörwald]

Martin Blais wrote:

> On 6/5/06, Walter Dörwald <walter at livinglogic.de> wrote:
>> >
>> > If you really care, then I suggest you should all agree on something,
>> > and then someone should show courage and convert all the existing
>> > tests to that thing (ideally, someone who cares).  I would be happy to
>> > comply with whatever thing you choose to agree on.
>>
>> The plan is to move all tests to unittest or doctest. This allows us to
>> add  useful features like leak or speed tests for each test function.
>> See
>> http://www.python.org/dev/summary/2003-01-01_2003-01-15/#no-expected-test-output-for-test-sort
>>
>> for an old thread about this topic.
>>
>> So IMHO this patch show be reverted.
> 
> There are two tasks to be done:
> 
> 1) add a couple of new tests to the struct module
> 2) convert all the code to use unittest
> 
> They are separate tasks.  I agree with you that the code should be
> converted to use unittest, not just this file, but all the files.

It seems that test_struct used a mixture of adhoc tests and unittest
before, so reverting your checkin would just restore this. The right
thing to do IMHO is to convert the complete script to unittest.

> This is however a separate task, this belongs in a separate revision,
> and those changes will probably touch many of the test files as well.

Yes, but changing tests to unittest has been done script by script over
the last years.

And according to

   $ ll test_*.py | wc -l
   319
   $ grep -l "import unittest" test_*.py | wc -l
   199

we're 62% done.

> If a new contributor like me has to convert other pile of people's
> code everytime he touches it lest his contributions be reverted,
> you're adding an extraordinary barrier to contributions.

True, test_struct was a special case.

> I went for
> consistency with existing code and working code over waiting for weeks
> until I have free time to look further into the implications of
> changing other people's code (which will undoubtedly open a different
> can of worms and right now I just don't have time to get into this,
> I'm focusing on one thing).   This is also what the other developers
> did at the need-for-speed sprint.  I think the patch should stay, it's
> working code that is consistent with the rest of the existing code.

OK, but it should be converted to unittest eventually.

Servus,
   Walter