[openstack-dev] [Fuel] py.test vs testrepository

Robert Collins robertc at robertcollins.net
Mon Oct 5 17:48:00 UTC 2015

On 6 October 2015 at 03:34, Roman Prykhodchenko <me at romcheg.me> wrote:
> Disclaimer:
> I didn’t want to fire up this war but it silently hit one of my patches so now I think it’s better to spread it to a wide audience.
> When I was dealing with one of the regular dependency hell in Fuel Client I noticed, that stuff which is not in global requirements may make the mentioned hell hotter, even if those requirements are test requirements. After that discovery I started aligning all *requirements.txt to Kilo’s global requirements and trying to remove everything which it not there. A special dependency is of course py.test: replacing it is a very controversial thing which I’d like to discuss here.
> Atm I have the following pros. and cons. regarding testrepository:
> pros.:
> 1. It’s ”standard" in OpenStack so using it gives Fuel more karma and moves it more under big tent
> 2. It’s in global requirements, so it doesn’t cause dependency hell

I'd also add that it enables the big data approach to test analysis
that the subunit2sql and test dashboard folk are building up, and
thats pretty important. A subunit py.test plugin would enable that for
py.test test authors (and in fact that would enable testing via
py.test under testrepository - test repository is *not* a test runner
- its a data-store + a meta-runner).

> cons.:
> 1. Debugging is really hard

It is really hard indeed, and I'd like love to fix that. In fact I'd
like to make it as nice as it is in py.test - I have a plan, and I'd
be delighted to turn it into a spec that someone can follow if anyone
would like to fix this - I think it would be quite high leverage a
thing. OTOH, because its an exercise in distributed systems
programming, its not truely trivial.


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the OpenStack-dev mailing list