Forum Discussion

Marramreddy's avatar
Occasional Contributor
5 years ago

Is context property shared a cross test cases ?

I am creating "context.variableName = new foo()" for every test case in EVENTS under testrunner.beforerun


Here are the steps for every test case:

1. Create a context variable in beforerun

2. Test Steps (access the context variable in the test steps)

3. kill context variable in afterrun


I have 5 test cases in a test suite, so when I execute from Test suite level in parallel. Every time one or the other test case fail because it could not find context variable. 


My guess:

Context variable are shared across the test cases, as I am killing the context variable afterrun its creating problem.


What I need to Understand:

Is context property shared a cross test cases ?



6 Replies

  • nmrao's avatar
    Champion Level 3
    I think you already put the answer after the tests.
  • Lucian's avatar
    Community Hero

    I am sorry but I don't know the answer to the question. Instead I would ask why use this approach? What is your use case here? If you need a global variable, why not just use a project property instead?

    • Marramreddy's avatar
      Occasional Contributor

      Use case: Initialize the java class once and use the class object in all the test cases.


      I should be able to run single test case.

      I should be able to run test suit.


      We can't set objects as project properties.


      I don't think this is a new or unique use case.



      • JoostDG's avatar
        Frequent Contributor

        Not sure if I understand the use case, but I believe I encountered 'something' similar when I used a filter request event handler for authorization header injection. Each request needed it's particular (openid) authorization header. Based upon a parameter from the request it went and find the corresponding authorization header that was available as a project property. These authorization headers (tokens) were created at the first test suite of my project.

        This all worked fine when running in sequence, but for a test suite that ran its testcases in parallel I noticed this went wrong. Problem was that the filterRequest was not thread safe, so the parallel runs interfered with eachother and wrong authentication headers were submitted. I could not find away to get around this, so in my case, I solved this by 'manualy' adding the authentication headers for these requests in parallel and used a test suite setup script to detect the run type. When this run type equaled "parallel" I disabled the event handler. Teardown made sure to enable it again for my next (sequence) test suites.