feat: Add RSpec/ContextMethod rule only as warning

[DaniPB]

What is the goal?

Improve clarity, readability, consistency, and avoid ambiguity in our RSpec tests by adding the RSpec/ContextMethod rule.

🤓 Using describe and context methods explicitly communicates the code's intention more clearly, making it easier for other developers to understand the structure of the tests.

Currently, we have 186 offenses to this rule.

Is this a restricting or expanding change?

RESTRICTING change

References

• Related pull-requests: https://github.com/sequra/simba/pull/8245

How is it being implemented?

I just added the rule to default.yml

Opportunistic refactorings

No

Caveats

I'll fix the 186 offenses in PRs like this one https://github.com/sequra/simba/pull/8245 after this rule is approved 🤞🏽 💕

[mdeniz]

LGTM 🌮

[valdis]

I find that warnings are often ignored. If a rule does not throw a failure in the CI pipeline, we'll have a lot of cases where developers don't notice this.
So the suggestion would be to make it as a propoer error.
The CI pipeline only checks changed files, so you don't have to worry that you'll get all the errors in the next PR

[gorka-sq]

I find that warnings are often ignored. If a rule does not throw a failure in the CI pipeline, we'll have a lot of cases where developers don't notice this.

@valdis Agreed. We have a card in our backlog to review this flow 👍

[DaniPB]

@valdis Thank you for pointing this out. @gorka-sq, Do you think we should keep it as info or do we make the CI pipeline fail?

Also, I'd be fixing most of the offenses I don't think it should be a problem to remove the info, I just added it to follow our guidelines 😊

[gorka-sq]

@DaniPB some of our projects run rubocop in full-mode, that's why we decided to take this informational mid-step. For now we are keeping it, but we will review this process soon(-ish) to remove the bureaucracy it introduces.