I'm very happy to hear that context-fixtures will land in py.test 2.4 one way or another. I just wanted to comment about API. As I understand, the following use-case is the only reason against @pytest.fixture supporting context-fixtures.
 
    @pytest.fixture
    def genfix():
        yield 1
        yield 2
 
I have never seen this use-case, but if I did, I would point it out as a bad example of ad-hoc test parameterization. So I would go for @pytext.fixture supporting context- and normal fixtures, without any parameters to the decorator, because:
 
1. that makes for a simpler API (same decorator, no new parameters),
2. it is only a minor breaking change (for a weird use-case only),
3. if someone really needs to return generator from a fixture they still can:
 
    @pytest.fixture
    def genfix():
        yield (x for x in range(20))
 
And I'm sure that context-fixtures will quickly catch up in popularity, just take a look for a second how readable it makes the finalization step; the whole fixture reads naturally top-down:
 
    @fixture
    def db():
        db = DataBase()
        yield db
        db.close()
 
I would even advertize this as the default way to make fixtures in py.test documentation.
 
Compare to current API:
 
    @fixture
    def db(request):
        db = DataBase()
        request.addfinalizer(lambda: db.close())
        return db
 
—Vladimir
_______________________________________________
Pytest-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pytest-dev

Reply via email to