[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