This repository was archived by the owner on Jun 27, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 27, 2019. It is now read-only.
Sharing a storeText variable between tests in a testsuite? #161
Description
i'm using | $VariableName= | is | storeText | on | //*[contains(@class, 'testPanel')]| to create a variable and later use this variable with | ensure | do | sendKeys | on | //*[contains(@id, 'textbox')]| with | $VariableName|
This works perfectly within a single test. However, Xebium/Fitnesse, seems to forget this variable when the next test in the suite opens.
How can I share variables between tests within a testsuite ?
Activity
cwortel commentedon Jun 8, 2016
Tests should not be dependent on each other, so FitNesse does not support
it out of the box. Why is the value for the class not constant? What is the
problem you try to solve, maybe there is an alternative way to reach the
same goal.
On Fri, Jun 3, 2016 at 8:44 AM, pmmvr notifications@github.com wrote:
pmmvr commentedon Jun 8, 2016
Thanks for your reply.
Let's say my suite consists out of 5 test cases.
The only reliable way of ensuring the product from test case one is selected is by using the unique product ID. Due to heavy use on the test-environment it is almost impossible to predict this generated ID and testing this function is also not part of my testing scope.
If I understand you correctly, you would advice me to group these tests within one Fitnesse-testPage instead of grouping them in a testSuite using individual test-pages for each test-case?
Anyway, i did notice that within a suite, Xebium does reuse a earlier stored variable when using input commands such as
typeandsendKeysbut seems to "forget" the variable when using assertion commands such aswaitForTextorassertValue. Would this be a bug?cwortel commentedon Jun 8, 2016
Hmm that is strange behaviour. There is a differente between ‘fitnesse’ type variables and web driver internal variables. It might be something to do with that. But I would say that if one works the other should have the same behaviour. Unfortunately I don’t have time to dig into it right now. For now he quick workaround would be to store them in one page.
If you really want to make solid tests and solve the problem, I would advise you run the tests in an isolated environment where you have a control over your data. In this setup you would have a fixture that allows to write data to my system, than run a focused tests using precisely that data, and start the next test. The next tests would start with cleaning the data of the first test, write new relevant data and again run a specifically focussed tests.
Automation within a heavy used integrated environment is a bit an anti pattern, as is having depending tests, or combining different tests into one. If one test fails its practically impossible to trace what caused it and all following tests will fail as well. It’s not very fault tolerant or maintenance friendly.
Hope this helps you somehow.