[py-dev] Testing and Coverage against different python interpreter versions

holger krekel holger at merlinux.eu
Mon Apr 26 18:03:31 CEST 2010


On Tue, Apr 27, 2010 at 00:00 +1000, meme dough wrote:
> > I looked into the new plugin and have some immediate issues/questions:
> >
> > - ETOOMANYCMDLINEOPTIONS ...
> >  could most of the command line options go away
> >  if we rather rely on configurability through the config file?
> 
> Yes/No, while more cmd options with -h that maybe take up more space,
> it does give lots of control of coverage.  I think this is good.  It
> could move some of them to config file only but I don't think it good
> to remove completely.
> 
> The good thing with pytest is the cmd options are auto done for
> conftest and env var which you can see with the --help-config with no
> work to do and consistent.  Also all options have --cov prefix so
> clear and no clash.
> 
> If only downside is more output on -h then seems small con.

having around 10 options for one plugin makes it hard to know
what the canonical usage is.  And what happens if you have a mixed
config-file/cmdline option situation?  Also i doubt that e.g. being able
to control output directories for html, xml, annotate needs
to be that fine-grained, a '--cov-outputdir=...' is enough IMO. 

What about a generic --cov-option="...." that can be specified multiple 
times and can override config-ini values?  This way you can (if you want to) 
still specify details on the command line but generally have a single
place and way to specify config for coverage (in the ini file). 
 
> > - can you add basic (functional or unit) tests?
> 
> Was early release with loose ends because people expressed an
> interest, so can test drive and have look.
> 
> I have tests but are simple compared to real project testing with.
> Will commit when python versions issues are tidied up.
> 
> > - is there a need to have a pytest_cov package instead of just a single module?
> 
> Like this in preparation for rsync and activate plugin since better
> rsync dir I think, but your other email I like better.  For now just
> require coverage / pytest-cov installed on slaves.  But future have
> slave env setup through normal python way (distutils2 and
> virtualenv?).
> 
> I will likely change to just module, but it seems more style thing so
> not sure if matters too much either way it done.

great, thanks for getting back on the issues.

holger



More information about the Pytest-dev mailing list