I'm thinking we can probably convert the nose generative test functions to pytest parameterized tests -- http://pytest.org/latest/parametrize.html#parametrized-test-functions
I'm experimenting with it now... On Tue, Apr 7, 2015 at 12:31 PM, Thomas De Schampheleire < [email protected]> wrote: > Hi, > > On Tue, Apr 7, 2015 at 9:08 PM, Thomas De Schampheleire > <[email protected]> wrote: > > Hi Marc, > > > > On Tue, Apr 7, 2015 at 5:46 PM, Marc Abramowitz <[email protected]> > wrote: > >> 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. > >> > >> 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. > > > > Welcome indeed! I'm excited to get this pytest-adoption started. > > My hope is that this is not just one month, which is probably too > > short to fix the entire test suite. > > > > To get started, use following instructions to set up an environment: > > http://kallithea.readthedocs.org/en/latest/contributing.html > > > > You can run the existing testsuite from this virtualenv using > 'nosetests'. > > > > First step would indeed be to use pytest as test runner instead of > > nosetests. On IRC (#kallithea on freenode) Ronny already indicated a > > first blocker related to yield tests. > > > > Quick log: > > <ronny> patrickdp: atm there is one big pytest side blocker, detailed > > nose yield tests are not compatible with pytest yield tests > > <ronny> so right now the testsuite runs in a completely broken > > setupstate wrt yield tests > > <ronny> since the testsuite also uses very detailed checks with > > setup/teardown, a moinmoin style workaround (different > > collection/execution for generators) is not possible > > <ronny> (where not means not without lots of work) > > <ronny> im not yet sure of a good strategy to work that out > > <patrickdp> ronny: what exactly are 'yield tests' ? > > <ronny> patrickdp: yield tests are tests which use a toplevel yield to > > yield distinct checks to the test executor > > > > Any ideas to proceed are most definitely welcome here... > > > > It looks like the only test files that have yield tests are: > models/test_user_permissions_on_repo_groups.py > models/test_user_group_permissions_on_repo_groups.py > > In the tests in these files, the pattern is typically: > for name, perm in repo_items: > yield check_tree_perms, name, perm, group, 'repository.read' > > for name, perm in items: > yield check_tree_perms, name, perm, group, 'group.write' > > > where: > repo_items = [x for x in _get_repo_perms(group, recursive)] > items = [x for x in _get_group_perms(group, recursive)] > > and: > def check_tree_perms(obj_name, repo_perm, prefix, expected_perm): > assert repo_perm == expected_perm, ('obj:`%s` got perm:`%s` > should:`%s`' > % (obj_name, repo_perm, expected_perm)) > > > If yield tests are a problem, what about just transforming such yield > tests into simple tests? Each test function that is currently yielding > new test methods would become one simple test, iterating over the > items and repo_items and asserting for each combination, thus > replacing the yield statement with the assert itself. > > This may not be as nice as a test could fail due to many different > scenarios, but since there are only test files that have this problem > and since such yield tests are a blocking issue as said by Ronny, such > a solution could deblock pytest conversion. > > Thoughts? > > Thanks, > Thomas >
_______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
