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

[Enhancement] Linter to avoid spec pollution #136

Closed
frbvianna opened this issue Feb 22, 2024 · 0 comments · Fixed by #141
Closed

[Enhancement] Linter to avoid spec pollution #136

frbvianna opened this issue Feb 22, 2024 · 0 comments · Fixed by #141
Assignees
Labels
enhancement New feature or request

Comments

@frbvianna
Copy link

Is your feature request related to a problem? Please describe.

To avoid spec pollution and hard-to-debug issues, everyone should have Ginkgo's mental model in mind and follow the "Declare in container nodes, initialize in setup nodes", as stated here:
https://onsi.github.io/ginkgo/#avoid-spec-pollution-dont-initialize-variables-in-container-nodes

Ginkgo states at the end of this doc section:

Ginkgo currently has no mechanism in place to detect this failure mode, you'll need to stick to "declare in container nodes, initialize in setup nodes" to avoid spec pollution.

I'm not completely sure if ginkgolinter already has some rule to check this, but it seems like it would make much sense for a linter to capture this, especially considering that the tool does not. This is something that, if not captured in a PR review, can result in flaky tests. Even with the linter enabled, I've seen a bug happen in our project test code due to this same issue when --randomize-all flag was enabled, evidencing that one variable was not properly assigned in a setup/subject node.

Have you considered implementing a rule for this in the linter?

Describe the solution you'd like

To have a linter error suggesting that a variable should not have been initialized in a container node, but instead in a setup/subject node.

Describe alternatives you've considered

N/A

Additional context

N/A

@frbvianna frbvianna added the enhancement New feature or request label Feb 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants