Hi Ken, On Wed, May 13, 2015 at 15:42 -0400, Ken Petti wrote: > Hello all, > > Last week I spoke to Ronny on the IRC channel about a fixture issue, and he > recommended I send out an email to the larger group. Here is a gist of the > issuehttps://gist.github.com/citizenken/861055b8778c9cce343a > > I have a fixture on the module level that I want to override on a per-test > basis. This module fixture handles app log in and is both autoused and > function scoped. I override it with a tuple value, to use non-default > credentials, and then use the new fixture in an alternate login fixture.
hum, haven't used myself a setup like this yet. > What I expect to happen is that the module fixture it overridden with my > static values, the alternate login fixture then uses those static values > and logs in, then control goes to my tests, which executes as expected. > What is happening is that the module fixture is never overridden, so the > app logs in with the wrong credentials and the test fails. Why do you want to override the module level fixture instead of creating a new function level fixture if i may ask? (overriding fixtures should be rarely done IMO and not sure about modifying scope at the same time ...). > Ronny suggested modifying my gist and using hidden fixtures like so: > https://gist.github.com/RonnyPfannschmidt/3c17b07aa56d6231d38d Besides, is there a reason you use "module_conftest.py" instead of "conftest.py"? I'd think that "module_conftest.py" is not used at all unless you import it from "conftest.py" or so. holger > This did not work. Instead, the hidden fixture was executed with the static > values, then, without closing the browser, the original login_by_account > fixture is called. > > > > This is an excerpt from my chat with Ronny: > [13:25] <ronny> citken: i think you missunderstood me, the idea is to > separate th data fixture and the autouse fixture, since it seems all > autouse instaces are made n all cases > [13:27] <citken> ronny: can you show me an example/comment on the gist what > i should do? > [13:28] <ronny> citken: > https://gist.github.com/RonnyPfannschmidt/3c17b07aa56d6231d38d > [13:30] <citken> ok let me try that now > [13:30] <citken> thanks, that makes more sense > [13:31] <ronny> citken: could you please repost an issue about autouse > fixture overriding issues > [13:34] <citken> yeah that isn't working either > [13:34] <citken> my fixture is overriding for all test cases > [13:35] <citken> it should only override for the testcase that is marked > parameterize > [13:35] <citken> making the hidden fixture, as in your gist, does not work > correctly > [13:43] <ronny> then im missing something > [13:44] <ronny> citken: what is the problem with the hidden fixture/ > [14:01] <citken> ronny: so i don't think your gist is handling the override > correctly > [14:02] <ronny> citken: im probably missing something, what exactly is > happening how? > [14:04] <citken> its weird... it looks like _ensure_login is hit first > (expected, with autouse=True), and that has the value of my override. My > app logs in with the override credentials. Then, without closing the > browser or anything, the original login_by_account fixture is called, the > one with the scope of "function" > [14:04] <citken> is the stack trace like this?: > [14:05] <citken> override -> autouse fixture -> function scope fixture -> > test? > [14:07] <ronny> citken: not sure, i dont know the exact details, holger and > bubenkoff worked with fixture oerrides in-depth, and currently im at the > end of what i can help with > > > > > If anyone could give me a hand that would be great! Thanks! > -- > *Ken Petti* > Software Development Engineer in Test > E-Mail: [email protected] <[email protected]> > <http://www.cloudlock.com/> > <http://www.twitter.com/cloudlock> <http://www.facebook.com/cloudlock> > <http://www.linkedin.com/company/cloudlock> > <https://plus.google.com/106755360058827077409/posts> > *CloudLock provides compliance and security solutions for enterprises using > public cloud applications like Salesforce and Google Apps. The largest > organizations in the world trust CloudLock to secure their data*. > _______________________________________________ > pytest-dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/pytest-dev -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu _______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
