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

Hi Holger, On 11/27/2012 11:27 PM, holger krekel wrote:

...

@pytest.marks('red', 'green', 'blue', 'black', 'orange', 'pink') def some_test_method(self): # some check-y stuff

I can see how each mark consuming a line can be cumbersome. I wonder if there would be a way to have less line noise, however. For example::

@pytest.mark.red.green.blue.black.orange.pink def test_method(...): ...

I think that using the dot is a bad idea, because it conflicts with the standard meaning that it has in Python, i.e. to "navigate" between layers/levels. If we really want some syntactic sugar, the following is ugly but at least is not as confusing as the one above: m = pytest.mark @m.red/m.green/m.blue def test_method(...): ... Even if I have to admit that in my explicit-is-better-than-implicit opinion, the best ons is still the first. ciao, Anto