I am using marks to dynamically determine which Selenium scripts to run. It is not uncommon for Se based suites to take many hours to complete so being able to only run the subsection you want is invaluable. And having the collection based on marks really hinders the ability of people writing scripts that are dependent on other ones (which hurts parallelism, etc.)
More context; I use pytest as the underlying runner for a Selenium framework [1]. Since the scripts they create are 'functional' in nature they tend to cross various parts of their testing matrix. At minimum I coach them to have either 'shallow' or 'deep' as marks similar to how Google popularized the 'small', 'medium' and 'large' grouping. From there a method might have 'authentication', 'profile', 'admin' or any number of other marks of their choosing to slice-and-dice up their runs; 8 or 9 marks in not crazy in some suites I have seen. But yes, in your context I can see your approach being more suited for the task. -adam [1] http://element34.ca/saunter/pysaunter > Hi Adam, > > i am having trouble seeing a good use-case > for just throwing a bunch of marks at something, > > in my worldview marks are something to express intents/configurations > so if there is an intent that combines more than one mark, i think > that a function that properly configures/applies those marks > might make more sense > > so at least i don’t see a place where i would use EXCESS markers > > an example that comes to my mind where your utility could help would > be better creation of intent describing decorators > > eg. something like > > def needs_posixop(name): > return pytest.marks( > pytest.mark.posix, > #? shortcuts that for nonmarkers? > getattr(pytest.mark, name), > pytest.mark.skip_if( > not hasattr(os, name), > reason='no %r in sys' %(name,)) > ) > > @needs_posixop('dup') > def test_foo(): > ... > > > however im a bit under the impression that instead of throwing in > markers there, i'd would rather see something like the following > > > @pytest.mark.needs_posixop('dup', 'dup2') > def test_foo(): > ... > > and having other marks be expanded from that > > maybe with a new hook called pytest_makeitem_expandmark > (please find a better name) > > def pytest_makeitem_expandmarks(item, mark): > if mark.name == 'needs_posixops' > item.applymarker(pytest.mark.posix) > for op in mark.args: > item.applymarker(getattr(pytest.mark, op)) > item.applymaker(pytest.mark.skip_if(...) > > > so please provide a few more real world use-cases that make us see the > merit of this utility > > once we understand more about how and where it will be useful, > a normal pull request on bitbucket can be used to > push patches that extend the builtin marks plugin with the new > additions can be done > > best wishes, > Ronny Pfannschmidt > > > > On 11/26/2012 05:25 PM, Adam Goucher wrote: >> If I wanted to try and add https://github.com/adamgoucher/pytest-marks >> to the main pytest distribution. Is there a process for consideration, >> code style rules, etc.? >> >> The idea of this plugin is to allow script creators to not have to do >> >> @pytest.mark.red >> @pytest.mark.green >> @pytest.mark.blue >> @pytest.mark.black >> @pytest.mark.orange >> @pytest.mark.pink >> def some_test_method(self): >> # some check-y stuff >> >> but rather >> >> @pytest.marks('red', 'green', 'blue', 'black', 'orange', 'pink') >> def some_test_method(self): >> # some check-y stuff >> >> -adam >> _______________________________________________ >> py-dev mailing list >> py-dev@codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev > _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
