I just figured out a problem with the Python module 'unittest.py',
version 1.63.

The function '__init__' behaves a bit strange in certain circumstances.
It is called either directly from the command line or it is called when
unit tests are to be executeded from a script.
The latter form is used by the pyunit Ant task. It generates such a
python script an passes it into a python process. Example:

import unittest
s = open('PyUnit-report.log', 'w')
unittest.main(module=None,
              defaultTest=None,       
         argv=[plugins.Excel_5P_Import_Test','plugins.HDL_Import_Test',
                    'plugins.IPXact_Import_Test'],
              testRunner=unittest.TextTestRunner(stream=s))
 
The paroblem with this way of activating the unittest module is that
in the function parseArgs (lines 775 to 796) the first element from
argv is skipped:
 
778: options, args = getopt.getopt(argv[1:], 'hHvq',
779                                ['help','verbose','quiet'])
 
This way the first test module from the list of test modules passed in
by pyunit gets lost.

After analyzing your code I think it would be better to do the
skipping of the first element from argv directly in the __init__
method of the class 'TestProgram' at lines 760, 761. The code there
should look as follows:
 
760     if argv is None:
761         argv = sys.argv[1:]
 
This code would skip the first element from the argv array only when
the __init__ method would be called indirectly from the command line.

That change would be backwards incompatible with existing scripts calling main(...) programattically though.

Yes, the proposed fix would be an incompatible change. But my assumption is that in scenarios where main(...) is called programmatically the fix would correct an erroneous behavior. In these scenarios whatever is being passed as the first entry in the argv array gets lost currently. Possibly many users who already noticed this implemented a workaround (I changed the pyunit Ant task's code to add a dummy argument as the first element in the argv array).

I'm sure that there are many places using the API as it is, inserting a dummy entry into the argv they pass. Although the fix you propose would solve the problem for users who are currently using the API wrongly it would break code for people who are using it correctly. It is certainly an unfortunate API wart - but I don't think it is worth breaking people's code to fix it...