<div dir="ltr">The nose plugin that I was referring to: <a href="http://pylons-webframework.readthedocs.org/en/latest/testing.html#unit-testing-with-webtest">http://pylons-webframework.readthedocs.org/en/latest/testing.html#unit-testing-with-webtest</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 7, 2015 at 1:47 PM, Marc Abramowitz <span dir="ltr"><<a href="mailto:msabramo@gmail.com" target="_blank">msabramo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think the tricky thing is that Kallithea is using the Pylons nosetest plugin to initialize the Pylons app before the tests run. We will need to make it so that the Pylons app gets initialized before pytest runs tests -- probably by using conftest.py -- <a href="https://pytest.org/latest/plugins.html#conftest-py-local-per-directory-plugins" target="_blank">https://pytest.org/latest/plugins.html#conftest-py-local-per-directory-plugins</a></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 7, 2015 at 1:03 PM, Marc Abramowitz <span dir="ltr"><<a href="mailto:msabramo@gmail.com" target="_blank">msabramo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">http://pytest.org/latest/parametrize.html#parametrized-test-functions</a><div><br></div><div>I'm experimenting with it now...</div></div><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><br>
On Tue, Apr 7, 2015 at 9:08 PM, Thomas De Schampheleire<br>
<<a href="mailto:patrickdepinguin@gmail.com" target="_blank">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" target="_blank">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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>