Hi Adam, i took a few quick glances on pysaunter and the examples, It looks quite different from how *i* would expect it too look intuitively, which suggests that my understanding of your problem domain is too shallow.
Also from what i can see so far pysaunter takes in things from unittest and unittest2 as well. Since your use of py.test is quite different from most other uses i have seen so far, i'd like to allocate some more time for understanding the problem later. Note that we might come up with a different path to solving the problem in order to be more in align with the other advanced features of py.test (which require avoiding unittest/unittest2 TestCase subclasses) For now i think it makes sense to keep the marks plugin separate, since its current form grew out of your use-cases and environment, which isn't quite comparable to the usual way py.test is used. When i find the time to understand the problem domain i'd like to get back at you. In particular, since i noticed that various parts of pysaunter and the examples could benefit from better integration in reporting and execution from the pytest side (which needs some more work in pytest itself) best wishes, Ronny Pfannschmidt On 11/26/2012 08:45 PM, Adam Goucher wrote: > 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
