[TIP] RFC: Barely minimal CI + tests + packaging in Python WAS: Guidelines for where to put tests & how to package them

[Olemis Lang]

On Thu, Feb 25, 2010 at 12:36 PM, Olemis Lang <olemis at gmail.com> wrote:
> On Thu, Feb 25, 2010 at 12:29 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 12:10 PM 2/25/2010 -0500, Olemis Lang wrote:
>>>
>>> Thnx for your reply !
>>>
>>> On Thu, Feb 25, 2010 at 12:00 PM, P.J. Eby <pje at telecommunity.com> wrote:
>>> > At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote:
>>> >>
>>> >> PS: BTW, how could I trigger easy_install(ation) at a given point
>>> >> while implementing a distutils command, and let the command perform
>>> >> further actions if deps are installed correctly ?
>>> >
>>> > Setuptools' "Distribution" object has a method for fetching
>>> > dependencies.
>>> >  See setuptools' "test" command for an example.  (This doesn't install
>>> > the
>>> > dependencies globally, just drops eggs into the build directory.  But
>>> > they're there and available to be reused for installation in a later
>>> > phase,
>>> > under normal circumstances.)
>>> >
>>>
>>> So this means that setuptools `test` command already retrieves
>>> dependencies ?
>>
>> Yes - it also retrieves any testing-specific dependencies (per the
>> "tests_require" setup() argument), so that if you use another testing
>> library like py.test or nose, it can be used instead.
>>
>>
>>> If so, then I shouldn't care about that, because I'd only need to
>>> override `run_tests` method in order to do what I want to do (i.e. use
>>> another test runner ;o)
>>
>> In that case, you may want to simply use the setuptools trunk version
>> (setuptools==dev), which supports a test_runner setup() argument to the test
>> command.  ;-)
>>
>
> Ooops ! Almost nothing to do then, and I can happily add setuptools to
> my list to get a barely minimal build script for CI.
>

Well not as happily as I thought in first place. The fact is that
`setuptools` test command creates the runner by calling the class
specified in `test_runner` arg but supplies no parameters. In this
case I'd like to specify `xmlrunner:XMLTestRunner` (is that the
correct syntax ?) to obtain a JUnit XML report, but I need to specify
the path where those reports will be outputted, so that the CI tool
(Hudson in this case) can publish'em and generate the nice graphs we
all love . Considering the current implementation, I still need to
override `run_tests` method as a whole, and repeat 99% of what is
implemented in there, in order to get the exact runner I need

:(

My suggestion (hint, $0.02 ... whatever ;o) is

   1. use a factory method (e.g `create_runner` ) returning an
     instance of  test runner. This method could be overridden by
     subclasses if further options or whatever needs to be considered
     to instanciate the runner
  2. select an instance instead of a class

So far I prefer (1)

Something similar happens with loaders. For instance, if I was using
`dutest` loaders I wouldn't be able to specify parameters to
instantiate those loaders so, similar problem => similar solutions .

The goal is to make the command more flexible (easily extensible ?) to
support further options so as to instantiate runners and loaders

;o)

Comments ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free calculus 1.3.4 Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/O5E_yyBKv0U/