multiple @BeforeSuite conflict
Describe the bug I have 2 Step classes which both have "BeforeSuite" requirements, but they seem to conflict with each other, is this expected?
To Reproduce
1 — example spec:
./specs/foo.spec
# foo
tags: foo
## foo
* foo
## bar
* bar
2 — example spec api
./tests/step.foo.ts
import assert = require("assert");
import { BeforeSuite, Step } from "gauge-ts";
export default class StepFoo {
constructor( private foo: string = "foo" ) {
console.log("StepFoo constructed")
}
@Step("foo")
public async step() {
console.log("@StepFoo", { foo: this.foo })
assert(this.foo === "foo")
}
@BeforeSuite()
public async BeforeSuite() {
console.log("@BeforeSuite", { foo: this.foo })
assert(this.foo === "foo")
}
}
tests/step.bar.ts
import assert = require("assert");
import { BeforeSuite, Step } from "gauge-ts";
export default class StepBar {
constructor( private bar: string = "bar" ) {
console.log("StepBar constructed")
}
@Step("bar")
public async step() {
console.log("@StepBar", { bar: this.bar })
assert(this.bar === "bar")
}
@BeforeSuite()
public async BeforeSuite() {
console.log("@BeforeSuite", { bar: this.bar })
assert(this.bar === "bar")
}
}
3 — run it
$ npx gauge run --tags foo
StepBar constructed
StepFoo constructed
@BeforeSuite { bar: undefined }
Error Message: false == true
Stacktrace:
AssertionError [ERR_ASSERTION]: false == true
at StepFoo.<anonymous> (/Users/petermcintyre/nbos/git/trp-accepetance-tests/tests/step.bar.ts:19:9)
at Generator.next (<anonymous>)
at /Users/petermcintyre/nbos/git/trp-accepetance-tests/tests/step.bar.ts:17:71
at new Promise (<anonymous>)
at __awaiter (/Users/petermcintyre/nbos/git/trp-accepetance-tests/tests/step.bar.ts:13:12)
at StepFoo.BeforeSuite (/Users/petermcintyre/nbos/git/trp-accepetance-tests/tests/step.bar.ts:35:16)
at ExecutionStartingProcessor.<anonymous> (/Users/petermcintyre/nbos/git/trp-accepetance-tests/node_modules/gauge-ts/dist/processors/ExecutionProcessor.js:24:30)
at Generator.next (<anonymous>)
at /Users/petermcintyre/nbos/git/trp-accepetance-tests/node_modules/gauge-ts/dist/processors/ExecutionProcessor.js:8:71
at new Promise (<anonymous>)
Successfully generated html-report to => /Users/petermcintyre/nbos/git/trp-accepetance-tests/reports/html-report/index.html
Specifications: 0 executed 0 passed 0 failed 0 skipped
Scenarios: 0 executed 0 passed 0 failed 0 skipped
Total time taken: 272ms
Updates are available. Run `gauge update -c` for more info.
Expected behavior
if i remove one of the conflicting @BeforeSuite functions (eg. the one in bar.ts) — i everything works as-expected
❯ npx gauge run --tags foo
StepBar constructed
StepFoo constructed
@BeforeSuite { foo: 'foo' }
# foo
## foo @StepFoo { foo: 'foo' }
✔
## bar @StepBar { bar: 'bar' }
✔
Successfully generated html-report to => /Users/petermcintyre/nbos/git/trp-accepetance-tests/reports/html-report/index.html
Specifications: 1 executed 1 passed 0 failed 0 skipped
Scenarios: 2 executed 2 passed 0 failed 0 skipped
Total time taken: 301ms
Updates are available. Run `gauge update -c` for more info.
Screenshots NA
Desktop (please complete the following information):
- OS: macos
- Gauge and plugin version [run
gauge -v]Gauge version: 1.1.8 Commit Hash: b1501f4 Plugins ------- html-report (4.0.12) screenshot (0.0.1) ts (0.1.0) - Node version [run
node -v]: v12.16.2 - Npm version [run
npm -v]: 6.14.4
Additional context NA
@pwmcintyre The BeforeSuite hook is executed even before executing steps. If there are multiple BeforeSuite hooks, all of them will be executed one after another.
note: this appears to be for all hooks, not just @BeforeSuite (ie. any 2 matching hooks conflict with each other)
@BugDiver — let me try to clarify the issue
it's not the order they run, that seems to be fine ... the issue is that the instance on the second one seems to lose all its internal properties
eg — if i remove the assert so that it doesn't fail, and just observe the logs ... you can see the undefined properties:
$ npx gauge run --tags foo
StepBar constructed
StepFoo constructed
@BeforeSuite { foo: 'foo' }
# foo
@BeforeSpec { bar: undefined }
even though the constructor did run successfully!
@pwmcintyre I see what you mean. Let me check it from my end. I get back to
@pwmcintyre This should be fixed as part of #182