<div dir="ltr">I'm thinking we can probably convert the nose generative test functions to pytest parameterized tests -- <a href="http://pytest.org/latest/parametrize.html#parametrized-test-functions">http://pytest.org/latest/parametrize.html#parametrized-test-functions</a><div><br></div><div>I'm experimenting with it now...</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 7, 2015 at 12:31 PM, Thomas De Schampheleire <span dir="ltr"><<a href="mailto:patrickdepinguin@gmail.com" target="_blank">patrickdepinguin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><div class="h5"><br>
On Tue, Apr 7, 2015 at 9:08 PM, Thomas De Schampheleire<br>
<<a href="mailto:patrickdepinguin@gmail.com">patrickdepinguin@gmail.com</a>> wrote:<br>
> Hi Marc,<br>
><br>
> On Tue, Apr 7, 2015 at 5:46 PM, Marc Abramowitz <<a href="mailto:msabramo@gmail.com">msabramo@gmail.com</a>> wrote:<br>
>> Just wanted to say a quick hello. I volunteered for adopt pytest month. I have used pytest (and Tox as well, which I suspect could be useful here) quite a bit for both personal projects and my professional work - i.e.: my current work at SurveyMonkey.<br>
>><br>
>> I'll try to download and try out Kallithea soon (I've never used it), try out the test suite, etc. and see where we might be able to get some wins.<br>
><br>
> Welcome indeed! I'm excited to get this pytest-adoption started.<br>
> My hope is that this is not just one month, which is probably too<br>
> short to fix the entire test suite.<br>
><br>
> To get started, use following instructions to set up an environment:<br>
> <a href="http://kallithea.readthedocs.org/en/latest/contributing.html" target="_blank">http://kallithea.readthedocs.org/en/latest/contributing.html</a><br>
><br>
> You can run the existing testsuite from this virtualenv using 'nosetests'.<br>
><br>
> First step would indeed be to use pytest as test runner instead of<br>
> nosetests. On IRC (#kallithea on freenode) Ronny already indicated a<br>
> first blocker related to yield tests.<br>
><br>
> Quick log:<br>
> <ronny> patrickdp: atm there is one big pytest side blocker, detailed<br>
> nose yield tests are not compatible with pytest yield tests<br>
> <ronny> so right now the testsuite runs in a completely broken<br>
> setupstate wrt yield tests<br>
> <ronny> since the testsuite also uses very detailed checks with<br>
> setup/teardown, a moinmoin style workaround (different<br>
> collection/execution for generators) is not possible<br>
> <ronny> (where not means not without lots of work)<br>
> <ronny> im not yet sure of a good strategy to work that out<br>
> <patrickdp> ronny: what exactly are 'yield tests' ?<br>
> <ronny> patrickdp: yield tests are tests which use a toplevel yield to<br>
> yield distinct checks to the test executor<br>
><br>
> Any ideas to proceed are most definitely welcome here...<br>
><br>
<br>
</div></div>It looks like the only test files that have yield tests are:<br>
models/test_user_permissions_on_repo_groups.py<br>
models/test_user_group_permissions_on_repo_groups.py<br>
<br>
In the tests in these files, the pattern is typically:<br>
    for name, perm in repo_items:<br>
        yield check_tree_perms, name, perm, group, 'repository.read'<br>
<br>
    for name, perm in items:<br>
        yield check_tree_perms, name, perm, group, 'group.write'<br>
<br>
<br>
where:<br>
    repo_items = [x for x in _get_repo_perms(group, recursive)]<br>
    items = [x for x in _get_group_perms(group, recursive)]<br>
<br>
and:<br>
def check_tree_perms(obj_name, repo_perm, prefix, expected_perm):<br>
    assert repo_perm == expected_perm, ('obj:`%s` got perm:`%s` should:`%s`'<br>
                                    % (obj_name, repo_perm, expected_perm))<br>
<br>
<br>
If yield tests are a problem, what about just transforming such yield<br>
tests into simple tests? Each test function that is currently yielding<br>
new test methods would become one simple test, iterating over the<br>
items and repo_items and asserting for each combination, thus<br>
replacing the yield statement with the assert itself.<br>
<br>
This may not be as nice as a test could fail due to many different<br>
scenarios, but since there are only test files that have this problem<br>
and since such yield tests are a blocking issue as said by Ronny, such<br>
a solution could deblock pytest conversion.<br>
<br>
Thoughts?<br>
<br>
Thanks,<br>
Thomas<br>
</blockquote></div><br></div>