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.
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:
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-allflag 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