Replies: 7 comments
-
I definitely agree that your "undesirables" are not desirable. This issue deserves further consideration--although this syntax wasn't very painful in Objective-C, it certainly is in Swift. Thanks for prompting me to think about this problem, @listrophy! 👍 Obviously this isn't a great solution, but for what it's worth, I always use implicitly unwrapped types, i.e.: Question: does the following work? class MyQuickTest: QuickSpec {
let subject = Mutator()
override func spec() {
describe("Mutator") {
it("test 1") {
expect(subject.mutated).to(beFalse())
subject.mutate()
expect(subject.mutated).to(beTrue())
}
it("test 2") {
expect(subject.mutated).to(beFalse())
subject.mutate()
expect(subject.mutated).to(beTrue())
}
}
}
} |
Beta Was this translation helpful? Give feedback.
-
I imagine that one of these will fail since when the second runs |
Beta Was this translation helpful? Give feedback.
-
Will it, though? As @listrophy points out, a fresh instsance of Gonna have to actually try it locally, though! 😅 |
Beta Was this translation helpful? Give feedback.
-
I had to write it as follows: class MyQuickTest: QuickSpec {
let subject = Mutator()
override func spec() {
describe("Mutator") {
it("test 1") {
expect(self.subject.mutated).to(beFalse())
self.subject.mutate()
expect(self.subject.mutated).to(beTrue())
}
it("test 2") {
expect(self.subject.mutated).to(beFalse())
self.subject.mutate()
expect(self.subject.mutated).to(beTrue())
}
}
}
} The first expectation in "test 2" failed. |
Beta Was this translation helpful? Give feedback.
-
@paulyoung that's probably because the underlying XCTest framework only sees one test method: Here's what I think happens:
Because the See also the blog post I wrote back in June, specifically the part under "How XCTest Handles Multiple Tests in One TestCase" |
Beta Was this translation helpful? Give feedback.
-
I may be wrong, but I think XCTest is picking up the correct number of tests here--Quick overrides So this definitely deserves more attention, but I'm not sure that specifically is the issue here. Sent from my iPhone
|
Beta Was this translation helpful? Give feedback.
-
I'm thinking about this issue now after having worked on a related issue for swift-corelibs-xctest. The reason why the example given by @paulyoung doesn't work as expected is because, although XCTest is making a new instance for each test, those instances' properties aren't referenced by the test closures at all. Instead, the test closures which are being executed have captured the property values of the test case instance which Quick itself instantiates during its setup process. (See here) This isn't proposing a solution (yet, anyway), but I wanted to dump that here before I forget the context again! |
Beta Was this translation helpful? Give feedback.
-
Apple's builtin XCTest framework has a much simpler way to instantiate shared variables. This mechanism does not work with Quick.
Given the simple class:
I'd like to see a way to do this:
Apple does this in XCTest by instantiating a new object for each test method.
Currently, I'd have to do this, which seems overly verbose and has those gross
!
optional-smashers everywhere:Beta Was this translation helpful? Give feedback.
All reactions