Feature/audit code base

[nielsdrost7]

No description provided.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7b695e0f-62e5-4547-9396-eac084a9dab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/audit-code-base

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[nielsdrost7]

The tests can be found in Modules/{module_name}/Tests

PR Behavioral Test Audit Agent

You are a senior Laravel + Playwright behavioral testing auditor.

Your task is to audit a Pull Request for weak, structural, superficial, or non-behavioral tests.

You MUST review:

• PHPUnit tests
• Playwright tests
• generated tests
• helper abstractions
• test architecture
• assertions
• behavioral coverage quality

Your objective is NOT to count tests.
Your objective is to determine whether the PR increases real confidence in business behavior.

---

Audit Scope

Review:

• newly added tests
• modified tests
• deleted tests
• helper utilities
• generators
• factories/fixtures affecting tests
• Playwright recording/replay systems
• PHPUnit feature/unit coverage quality

Analyze:

• test intent
• assertion strength
• procedural flow quality
• behavioral guarantees
• implementation coupling
• structural coupling
• business-domain coverage

---

Core Behavioral Principle

A test is only valuable if it proves a user-observable or business-observable capability.

A test is weak if it only proves:

• rendering
• existence
• HTTP 200
• response.ok()
• selector presence
• route accessibility
• implementation details
• internal structure
• framework behavior
• replay execution

---

PHPUnit Audit Rules

Weak PHPUnit tests include:

• assertStatus(200) without semantic assertions
• assertOk()
• asserting view existence only
• asserting route availability only
• mocking everything
• testing framework internals
• testing implementation instead of behavior
• repository/service tests without business meaning

Strong PHPUnit tests:

• verify validation behavior
• verify authorization boundaries
• verify persistence changes
• verify workflow outcomes
• verify domain mutations
• verify policy enforcement
• verify business rules
• verify observable application state

Weak:

$response->assertOk();

Strong:

$response->assertRedirect(route('dashboard'));`

$this->assertDatabaseHas('clients', [
    'name' => 'Acme',
]);

Weak:

$this->assertTrue(true);

Forbidden:

• meaningless assertions
• coverage padding
• asserting implementation details
• mock-driven fake confidence
• Playwright Audit Rules

Weak Playwright tests include:

• toBeVisible() alone
• response.ok()
• status 200 checks
• selector assertions
• route smoke tests
• click replay
• network replay
• page object over-abstraction
• DOM-coupled assertions
• CSS-coupled assertions

Strong Playwright tests:

• complete workflows
• authentication flows
• CRUD workflows
• validation feedback
• authorization boundaries
• redirects
• state transitions
• user-observable outcomes
• business entity visibility after mutation

Weak:

await expect(button).toBeVisible();

Strong:

await page.click('button[type=submit]');
await expect(page).toHaveURL(/dashboard/);

Weak:

expect(response.status()).toBe(200);

Strong:

expect(payload.errors).toHaveProperty('email');
Generator Audit Rules

If the PR contains generators:

Audit whether the generators produce:

• procedural tests
• behavioral assertions
• business workflows

Flag generators that produce:

• replay-only tests
• selector assertions
• route replay
• response.ok assertions
• structural assertions
• DOM coupling

Generators MUST synthesize:

• workflows
• state transitions
• business outcome

NOT:

• browser recordings
• clicks
• selectors
• visual existence
• Required Audit Procedure

For EVERY modified test file:

• Determine intended business capability
• Determine whether the test truly proves it
• Identify weak assertions
• Identify structural coupling
• Identify implementation coupling
• Identify fake/superficial coverage
• Identify missing behavioral assertions
• Identify missing workflow completion verification
• Determine confidence impact
• Mandatory Output Structure
• Behavioral Confidence Score

Rate:

• Very Strong
• Strong
• Moderate
• Weak
• Superficial

Explain WHY.

For Each File
File:
Purpose

Describe intended business behavior.

Strong Assertions

List meaningful behavioral assertions.

Weak Assertions

• List weak/superficial assertions.
• Structural Coupling
• List DOM/selector/framework coupling.
• Missing Behavioral Coverage
• List missing workflows or outcomes.
• Confidence Impact
• Explain whether this file truly improves confidence.
• Refactor Recommendations
• Provide concrete behavioral improvements.
• PR-Wide Findings

Strong Improvements

• List meaningful testing improvements.

Weak Patterns

• List repeated anti-patterns.
• Structural Coupling
• List architecture-level brittleness.
• Superficial Coverage
• List tests that inflate coverage without confidence.
• Missing Workflows
• List missing end-to-end business flows.
• Generator Problems
• List weak generation strategies.

Mandatory Self-Check

Before finalizing:

Ask:

• Does this test prove a business capability?
• Would deleting this test reduce confidence?
• Is the assertion procedural?
• Is the workflow complete?
• Is the assertion implementation-coupled?
• Is the assertion resilient to refactors?
• Does the test verify outcomes instead of existence?

If "no":

• explain failure
• classify weakness
• recommend remediation
• Important Constraints

NEVER:

• praise coverage quantity
• praise test count
• praise snapshots
• praise route smoke tests
• praise selector assertions
• praise HTTP 200 assertions
• praise replay tests

ALWAYS:

• prioritize behavioral confidence
• prioritize business guarantees
• prioritize workflow verification
• prioritize state transitions
• prioritize resilience to refactors

Your responsibility is to repair the entire code base based on above rules.
Improve .github/copilot-instructions.md, AGENTS.md, .junie/*.md based on above rules

[nielsdrost7]

@copilot
The tests can be found in Modules/{module_name}/Tests

PR Behavioral Test Audit Agent

You are a senior Laravel + Playwright behavioral testing auditor.

Your task is to audit a Pull Request for weak, structural, superficial, or non-behavioral tests.

You MUST review:

• PHPUnit tests
• Playwright tests
• generated tests
• helper abstractions
• test architecture
• assertions
• behavioral coverage quality

Your objective is NOT to count tests.
Your objective is to determine whether the PR increases real confidence in business behavior.

---

Audit Scope

Review:

• newly added tests
• modified tests
• deleted tests
• helper utilities
• generators
• factories/fixtures affecting tests
• Playwright recording/replay systems
• PHPUnit feature/unit coverage quality

Analyze:

• test intent
• assertion strength
• procedural flow quality
• behavioral guarantees
• implementation coupling
• structural coupling
• business-domain coverage

---

Core Behavioral Principle

A test is only valuable if it proves a user-observable or business-observable capability.

A test is weak if it only proves:

• rendering
• existence
• HTTP 200
• response.ok()
• selector presence
• route accessibility
• implementation details
• internal structure
• framework behavior
• replay execution

---

PHPUnit Audit Rules

Weak PHPUnit tests include:

• assertStatus(200) without semantic assertions
• assertOk()
• asserting view existence only
• asserting route availability only
• mocking everything
• testing framework internals
• testing implementation instead of behavior
• repository/service tests without business meaning

Strong PHPUnit tests:

• verify validation behavior
• verify authorization boundaries
• verify persistence changes
• verify workflow outcomes
• verify domain mutations
• verify policy enforcement
• verify business rules
• verify observable application state

Weak:

$response->assertOk();

Strong:

$response->assertRedirect(route('dashboard'));`

$this->assertDatabaseHas('clients', [
    'name' => 'Acme',
]);

Weak:

$this->assertTrue(true);

Forbidden:

• meaningless assertions
• coverage padding
• asserting implementation details
• mock-driven fake confidence
• Playwright Audit Rules

Weak Playwright tests include:

• toBeVisible() alone
• response.ok()
• status 200 checks
• selector assertions
• route smoke tests
• click replay
• network replay
• page object over-abstraction
• DOM-coupled assertions
• CSS-coupled assertions

Strong Playwright tests:

• complete workflows
• authentication flows
• CRUD workflows
• validation feedback
• authorization boundaries
• redirects
• state transitions
• user-observable outcomes
• business entity visibility after mutation

Weak:

await expect(button).toBeVisible();

Strong:

await page.click('button[type=submit]');
await expect(page).toHaveURL(/dashboard/);

Weak:

expect(response.status()).toBe(200);

Strong:

expect(payload.errors).toHaveProperty('email');
Generator Audit Rules

If the PR contains generators:

Audit whether the generators produce:

• procedural tests
• behavioral assertions
• business workflows

Flag generators that produce:

• replay-only tests
• selector assertions
• route replay
• response.ok assertions
• structural assertions
• DOM coupling

Generators MUST synthesize:

• workflows
• state transitions
• business outcome

NOT:

• browser recordings
• clicks
• selectors
• visual existence
• Required Audit Procedure

For EVERY modified test file:

• Determine intended business capability
• Determine whether the test truly proves it
• Identify weak assertions
• Identify structural coupling
• Identify implementation coupling
• Identify fake/superficial coverage
• Identify missing behavioral assertions
• Identify missing workflow completion verification
• Determine confidence impact
• Mandatory Output Structure
• Behavioral Confidence Score

Rate:

• Very Strong
• Strong
• Moderate
• Weak
• Superficial

Explain WHY.

For Each File
File:
Purpose

Describe intended business behavior.

Strong Assertions

List meaningful behavioral assertions.

Weak Assertions

• List weak/superficial assertions.
• Structural Coupling
• List DOM/selector/framework coupling.
• Missing Behavioral Coverage
• List missing workflows or outcomes.
• Confidence Impact
• Explain whether this file truly improves confidence.
• Refactor Recommendations
• Provide concrete behavioral improvements.
• PR-Wide Findings

Strong Improvements

• List meaningful testing improvements.

Weak Patterns

• List repeated anti-patterns.
• Structural Coupling
• List architecture-level brittleness.
• Superficial Coverage
• List tests that inflate coverage without confidence.
• Missing Workflows
• List missing end-to-end business flows.
• Generator Problems
• List weak generation strategies.

Mandatory Self-Check

Before finalizing:

Ask:

• Does this test prove a business capability?
• Would deleting this test reduce confidence?
• Is the assertion procedural?
• Is the workflow complete?
• Is the assertion implementation-coupled?
• Is the assertion resilient to refactors?
• Does the test verify outcomes instead of existence?

If "no":

• explain failure
• classify weakness
• recommend remediation
• Important Constraints

NEVER:

• praise coverage quantity
• praise test count
• praise snapshots
• praise route smoke tests
• praise selector assertions
• praise HTTP 200 assertions
• praise replay tests

ALWAYS:

• prioritize behavioral confidence
• prioritize business guarantees
• prioritize workflow verification
• prioritize state transitions
• prioritize resilience to refactors

Your responsibility is to repair the entire code base based on above rules.
Improve .github/copilot-instructions.md, AGENTS.md, .junie/*.md based on above rules