You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider the following suite running in the main thread (not on a fork itself):
suitedef errorSuite gets a b c with
// variables a, b, and c are non-null here (as expected)
// first call to a suite on a fork
suite someSuiteOnFork on fork01
// variables a, b, and c are still non-null here (as expected)
// some other calls (on fork or not does not make a difference)
// variables a, b, and c are still non-null here (as expected)
// LAST call to a suite on a fork within this suite
suite someSuiteOnFork on fork01
// ERROR: at this point, variable a is null (not expected)
suiteend
Note: The suite 'someSuiteOnFork' did not contain any variables which could result in a naming conflict with variables from the parent suite.
The erroneous behaviour was observed when the errorSuite was called as follows:
The error did NOT occur when passing a constant value directly as parameter 'a'.
We did not evaluate if the order of passing the arguments from root suite actually makes a difference in this case, or somehow influences which variable (if any) suddenly loses its value. However, in the scenario which caused the error, the affected variable was NOT declared as the last variable in the suitedef, but was passed as the last variable when calling the suite (as in above example). Perhaps this hint helps with further analysis.
The text was updated successfully, but these errors were encountered:
I have attempted to reproduce this bug (using Integrity 0.16.5), but was unable to do so. I used the following complete script, with the suite "asuite" as root suite (the "echo" fixture just returns whatever is provided to it):
import mypackage.*
import mysecondpackage.*
packagedef mypackage with
forkdef fork1
suitedef asuite with
variable myA
assign 100.00 -> myA
variable myB
assign 200.00 -> myB
variable myC
assign 300.00 -> myC
suite errorSuite
b: myB
c: myC
a: myA
test echo echo: myA = "100.00"
test echo echo: myB = "200.00"
test echo echo: myC = "300.00"
suiteend
suitedef errorSuite gets a b c with
// variables a, b, and c are non-null here (as expected)
// first call to a suite on a fork
suite someSuiteOnFork on fork1
// variables a, b, and c are still non-null here (as expected)
test echo echo: a = "100.00"
test echo echo: b = "200.00"
test echo echo: c = "300.00"
// some other calls (on fork or not does not make a difference)
// variables a, b, and c are still non-null here (as expected)
// LAST call to a suite on a fork within this suite
suite someSuiteOnFork on fork1
test echo echo: a = "100.00"
test echo echo: b = "200.00"
test echo echo: c = "300.00"
suiteend
suitedef someSuiteOnFork with
test echo echo: "blah" = "blah"
suiteend
packageend
I must have missed something, or there is something slightly wrong in the minimized example provided...
Consider the following suite running in the main thread (not on a fork itself):
Note: The suite 'someSuiteOnFork' did not contain any variables which could result in a naming conflict with variables from the parent suite.
The erroneous behaviour was observed when the errorSuite was called as follows:
The error did NOT occur when passing a constant value directly as parameter 'a'.
We did not evaluate if the order of passing the arguments from root suite actually makes a difference in this case, or somehow influences which variable (if any) suddenly loses its value. However, in the scenario which caused the error, the affected variable was NOT declared as the last variable in the suitedef, but was passed as the last variable when calling the suite (as in above example). Perhaps this hint helps with further analysis.
The text was updated successfully, but these errors were encountered: