Announcement Announcement Module
No announcement yet.
conditionally mark application context as dirty Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • conditionally mark application context as dirty


    I am using Spring Test Context Framework, specifically DI to build and inject WebDriver instance to my Junit 4 integration test classes.
    All my integration test class share the same base test class which is responsible for starting Spring Test Context Machinery, so for the whole integration tests suite i share the same WebDriver instance.
    PHP Code:
    ContextConfiguration({ "/selenium-webdriver.xml"})
    public class 
    protected WebDriver webDriver;
    public void clearCookies() {     

    This works really nice on my localhost, and on our CI server, but as we are doing some research on using SauceLabs, we were advised to start a new WebDriver instance per each test method.
    So when testing locally or on our CI we would like to have a single Webdriver instance per suite but in case of tests against SauceLabs create a single WebDriver per test method.
    Since we would like to define in the runtime a mode (webdriver per suite or webdriver per test method) we want our tests to be run, we are thinking of using spring bean profiles. Activation of profile could be done via setting system property. We have a couple ideas how we can solve it but honestly none of our ideas seems to be perfect:
    1) implementing per-test-method proxy of Webdriver for "webdriver per test method" profile. Could work but would require scanning execution stack within proxy to determine if new Webdriver instance needs to be created (i.e if we are inside new test method)
    2) Extend DirtiesContextTestExecutionListener and have context removed after each test method if given profile/env property is set
    3) in "webdriver per test method" profile create custom Junit4 Rule bean, have it injected to AbstractWebDriverInitiator and after test method let it close current webdriver, build/retrieve new webdriver and put it to application context to have it wired for next test method execution.

    The option 3 seems the most clean approach but it is the one that requires the most development effort.
    Does anyone have any comments on our ideas or can propose something better?

  • #2
    Waiting for help/suggestions/comments from forum members we found out a new approach which seems to be a little bit better:
    1) create new TestExecutionListener that exposes TestContext object in thread local
    2) create custom junit rule that retrieves TestContext from threadlocal and dirties it,