Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow @TestState properties be declared inside describe and context #5803

Open
2 tasks done
kasrababaei opened this issue Sep 20, 2024 · 1 comment
Open
2 tasks done
Labels
enhancement Ideas for improvements of existing features and rules. good first issue Issue to be taken up by new contributors yet unfamiliar with the project.

Comments

@kasrababaei
Copy link
Contributor

kasrababaei commented Sep 20, 2024

New Issue Checklist

Feature or Enhancement Proposal

Quick has a property wrapper called TestState which warrants there's no shared state between multiple tests by assigning the wrapped value to nil before each run.

However, the following example would trigger a quick_discouraged_call warning.

class TotoTests: QuickSpec {
   override func spec() {
       describe("foo") {
           @TestState var foo: Foo! = Foo() // <- triggers a warning
           context("bar") {
              @TestState var bar: Bar! = .init() // <- triggers a warning
              it("does something") {
                  bar.toto()
              }
           }
       }
   }
}

That's because the property is getting assigning by calling a function inside a describe/context.

I was wondering if it makes sense to not trigger when a using @TestState property. I can even look into putting up a PR (and appreciate any suggestion that can help me).

@SimplyDanny
Copy link
Collaborator

I'm not familiar with Quick, but what you describe and what I see in the implementation of @TestState in the Quick repository is that initializers are encouraged at this place. So this sounds like a reasonable exclusion.

@SimplyDanny SimplyDanny added enhancement Ideas for improvements of existing features and rules. good first issue Issue to be taken up by new contributors yet unfamiliar with the project. labels Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Ideas for improvements of existing features and rules. good first issue Issue to be taken up by new contributors yet unfamiliar with the project.
Projects
None yet
Development

No branches or pull requests

2 participants