Mailman 3 January 2016 - pytest-dev

pytest sprint 2016 / getting started
by holger krekel Feb. 9, 2016

Feb. 9, 2016

Hey all, let's try to find out if we can make a pytest sprint happen in 2016. Here are some suggestions/thoughts on key points. Participants: anyway who has contributed to pytest in recent years but also interested newcomers/wanna-be-contributors. Contributors are eligible for getting their travel costs reimbursed (see funding below). Location: somewhere around Freiburg, black forest, Germany. Date ranges: 20-26th June or 30th June - 6th July. Travel: arrive on the first day, leave the last. Funding: we'll do a Indiegogo or betterplace.org campaign and ask companies and individuals to help come up with funding for travel costs, lodging and food for participants. If participants can come on their company's time and money even better. In fact, the gathering will be a great opportunity to dive deeper into pytest and make the best use of it for your company. sprint contents: pytest-3.0 and a major new revision of the xdist plugin? Cleaning up wards, introducing new features (to be continued ...). deadline for funding compaign: maybe February/March so everybody can start booking. Who'd be up for it? how much do you estimate you need for travel? Would the date range fit? best, holger

10 17

sprint funding draft for end june 2016
by holger krekel Jan. 31, 2016

Jan. 31, 2016

Hey all, i made a sprint-funding draft here: https://github.com/pytest-dev/pytest/pull/1346 feel free to also discuss here. best, holger

3 2

Re: [pytest-dev] sprint funding draft for end june 2016
by Tom Viner Jan. 30, 2016

Jan. 30, 2016

Hi all, I'd also be interested in attending the sprint. My flight costs look to be about £100 (€130). Cheers, Tom Viner On 29 January 2016 at 17:00, <pytest-dev-request(a)python.org> wrote: > > Date: Fri, 29 Jan 2016 14:01:33 +0000 > From: holger krekel <holger(a)merlinux.eu> > To: pytest-dev <pytest-dev(a)python.org> > Subject: [pytest-dev] sprint funding draft for end june 2016 > Message-ID: <20160129140133.GI3793(a)merlinux.eu> > Content-Type: text/plain; charset=us-ascii > > > Hey all, > > i made a sprint-funding draft here: > > https://github.com/pytest-dev/pytest/pull/1346 > > feel free to also discuss here. > > best, > holger >

1 0

pytest docs on readthedocs?
by Bruno Oliveira Jan. 26, 2016

Jan. 26, 2016

Hi everyone, Currently one of the steps involved in the release process is manually generating the documentation and uploading to pytest.org (using rsync). I was wondering if we should move pytest docs over to readthedocs.org? It automatically builds and hosts the documentation based on tags or branches, so it would simplify the release build process a bit, plus it automatically hosts multiple versions of the documentation (would be nice to see how the docs for 2.9 in the features branch look like, for instance). Readthedocs even supports using canonical urls[1] so users would still access the documentation through pytest.org. Also, pytest.readthedocs.org already exists and hosts documentation for the 2.7.0 release. Ronny cleverly noticed that that release probably was the last release before moving to GitHub, otherwise it would be still serving up-to-date documentation as the project on readthedocs is still configured to clone the bitbucket repository. Holger, you are the owner[2] of pytest.readthedocs.org, do you remember if there was a reason to not fully move documentation hosting over there? What others think of this idea? [1] https://docs.readthedocs.org/en/latest/canonical.html [2] https://readthedocs.org/projects/pytest/ Cheers, Bruno.

5 11

Introduction
by Isaul Vargas Jan. 26, 2016

Jan. 26, 2016

Hi everyone! My name is Isaul Vargas and I work as a software tester. I have been using py.test since 2013 and I really like the fixture interface of Py.test it's a powerful abstraction! One of the libraries I use to test software is Selenium (and Appium for mobile devices), and one indispensable plug-in I use is pytest-xdist. I love how xdist lets me run tests in parallel, and initially it gave me the impression that tests were distributed among processes in a queue. However to my surprise, test distribution is batched and uneven; this is disappointing because if you're running slow functional, end-to-end tests, it's going to take a long time to run a big batch of tests, if the tests are distributed in an uneven manner. In my own test run of Appium tests, using -n 12, The initial batch of tests runs 12 processes; then when one or two tests finish, another one or two tests are dispatched. However after this initial batch, I only see about 6-8 active processes running. This is very disappointing, and I thought Python had an edge here, compared to other parallel test runners that only batch tests according to the number of processes/threads specified. (like Junit,TestNG on the Java side) So, I've decided to volunteer my time to help improve the Pytest-xdist plugin so that we have a true queue based system of test distribution so that every slot is always busy running tests, and save developers a ton of time! I would like to thank Ronny for taking the time to explain how the current system works, and what changes are needed to make this happen. I am motivated to get this issue fixed; so that we are the first test runner (that I know of) to use a queue based system that doesn't simply batch tests. For those wondering why batching is bad, when you have tests that take 2-3 minutes to complete, plus a few tests that take 5 minutes to complete; if you batch tests such that 1 workers gets all the 5 minutes tests and another workers gets all the short tests then the total run time is almost the same as running all the large tests in serial. I look forward to improving this aspect of pytest-xdist, and I am highly motivated to get this done. I look forward to diving deep into the code and learn the internals of pytest.

2 1

a potential alternative to the py.code merge
by Ronny Pfannschmidt Jan. 25, 2016

Jan. 25, 2016

Hi everyone, this is probably a bit late, in particular since Bruno did already spend a considerable amount of time, but instead of merging py.code for the exception repressentation, i would like to propose introducing a abstraction layer, and allowing to set the exception representation in pytest.ini or via plugins this would allow more free experimentation, and also a really clean transition from py.code as default * new possible, to py.code the legacy and new code the default. -- Ronny

3 5

on abolishing the feature branch concept
by Ronny Pfannschmidt Jan. 25, 2016

Jan. 25, 2016

Hi everyone, since it seems we collect more and more changes on the feature branch, that do not get released, i think it is time, to reevaluate if we should keep that workflow as is, from my pov we should focus more on using semver and simply bump versions as needed, and of course deliver more and all changes, instead of accumulating things somewhere without battle-testing. -- Ronny

4 16

Configurable collection roots and reusable testsuites - Brainstorming
by Ronny Pfannschmidt Jan. 25, 2016

Jan. 25, 2016

Hi everyone, a topic thats gripping since quite a while, is wanting to have reusable testsuites, so plugins/extensions that implement a behaviout, can import and use integration tests from a installed package, and use them in a different configuration another detail that plays into that is certain plugins needing different collections as well an example is the doctest-module, which should scan for doctests in the installed modules that where imported, and not the ones in the working directory. unfortunately its hard to find a good way to express those configured roots for collection, since the ini format on its own is rather limited, and i would like to avoid introducing sub-languagess -- Ronny

5 5

TLS certificate expired
by Brianna Laugher Jan. 25, 2016

Jan. 25, 2016

Hi, It was pointed out on Twitter that our tls certificate has expired. Cheers Brianna

4 3

how about merging features into master and a 2.9 release?
by Ronny Pfannschmidt Jan. 25, 2016

Jan. 25, 2016

Hi everyone, i think features made quite some accumulations, and its time for a 2.9 release, i propose to merge features into master after a cooldown period for 2.8.6 (i think 1-2 weeks is fine) afterwards a 2.9 release can be prepared -- Ronny

3 2