[@kbn/eslint-plugin-eslint] Add ESlint rule to allow max one describe call per fixture

[steliosmavro]

Summary

Adds a new ESLint rule scout_max_one_describe that enforces a maximum of one describe block per test type in Scout tests to maintain consistent test structure.

What it does

Scout tests support multiple test fixtures (apiTest, test, spaceTest), and each fixture type should only have one top-level describe block per file. This rule prevents multiple describe blocks for the same test type, which can lead to fragmented test organization.

Invalid:

test.describe('first suite', () => {
  test('test 1', () => {});
});

test.describe('second suite', () => {  // ❌ Second test.describe() not allowed
  test('test 2', () => {});
});

Valid:

test.describe('my test suite', () => {  // ✅ Only one test.describe()
  test('test 1', () => {});
  test('test 2', () => {});
});

Features

• Tracks apiTest.describe(), test.describe(), and spaceTest.describe() calls independently
• Reports errors immediately on second occurrence for each test type
• Allows 0 or 1 describe block per test type (not required, but max once if present)

Changes

• Added rule implementation with comprehensive test suite (12 test cases)
• Registered rule in plugin and enabled as error for Scout test files in .eslintrc.js
• Uses efficient single-pass tracking with immediate error reporting

[steliosmavro]

• I will need your insights on the file paths the rule should apply for. It's supposed to run for api tests, ui tests and space tests.
• The rule checks for describe calls per test type, but doesn't encourage multiple test types in the same file. Another rule can be introduced, discouraging multiple test types in the same file. Separation of concerns, each rule checks for its own thing. Although the introduction of such a rule might be redundant.
• Where should I add comments like this? Straight on the PR? Or on the project issue/task?

[dmlemeshko]

tbh not sure about it, but let's leave it as is for now

[dmlemeshko]

This test case is not valid: describe in global namespace is the Jest one, playwright Playwright.

Playwright/Scout nested describes already covered by the existing rules:

What is not covered is multiple top level describe in the same spec file.

[dmlemeshko]

Afaik this is will be interpreted as Jest test suites. Please double check

[dmlemeshko]

This is exactly the problem we try to detect!

[dmlemeshko]

I think we need to explain it is required for auto-skip functionality in CI. This argument should hopefully minimize interest to disable the rule.

[dmlemeshko]

I left few nits 👏

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: c52fe40

Failed CI Steps

• Linting

History

• 💔 Build #370202 failed 08e195b
• 💔 Build #369839 failed d82fa37

cc @steliosmavro

[steliosmavro]

I wasn't sure if I should include rule-violation fixes in this PR, so I decided to make a separate PR fixing 1 rule foundation that was found.

I suppose I should wait for the "rule-violation fixes" PR to be completed before moving on with this one?