Improper use of expect() in describe() block cause test-case enumeration to fail
KentLottis-jwn opened this issue · 2 comments
- I have read CONTRIBUTING and have done my best to follow them.
What did you do?
We found a malformed spec that had gone undiscovered under older versions of Quick/Nimble. Specifically, the spec author had failed to nest an expect()
clause inside an it()
block. Previously, this was silently ignored. Now it results in no tests being executed.
What did you expect to happen?
Ideally, we would get some sort of run-time diagnostic pointing to the coding error. At the very least, the other well-formed test cases in the spec should execute normally.
What actually happened instead?
The spec fails to run any tests.
Environment
List the software versions you're using:
- Quick: 7.2.0
- Nimble: 12.2.0
- Xcode Version: 14.3.1
- Swift Version: Xcode Default
Please also mention which package manager you used and its version. Delete the
other package managers in this list:
- Swift Package Manager 5.8.1
Project that demonstrates the issue
Easier to just paste in the repro case
I would expect this spec to result in one test failure. Instead, not tests are executed.
class BrokenSpec: QuickSpec {
override class func spec() {
describe("a well-formed describe") {
it("fails") {
expect("a").to(equal("b"))
}
}
describe("a malformed describe") {
// this is, of course, a coding mistake - there should be an enclosing it() block
// but it would be nice if the runtime would catch this
expect("a").to(equal("b"))
}
}
}
Note: one might think that this is actually an issue with Quick, since it concerns test-case enumeration (a Quick behavior) as opposed to assertion handling (the core Nimble behavior). However, if I replace the expect()
clause with an equivalent XCTAssertEqual("b", "a")
, then the test case is enumerated as desired.
Note: one might think that this is actually an issue with Quick, since it concerns test-case enumeration (a Quick behavior) as opposed to assertion handling (the core Nimble behavior). However, if I replace the expect() clause with an equivalent XCTAssertEqual("b", "a"), then the test case is enumerated as desired.
Fascinating. That doesn't seem like that should be the case.