Forum Discussion

Marramreddy's avatar
Marramreddy
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
    nmrao
    Champion Level 3
    I think you already put the answer after the tests.
  • Lucian's avatar
    Lucian
    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
      Marramreddy
      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
        JoostDG
        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.