PDD-CLI Bug: Assumes Component Library Structure Without Verification

## PDD-CLI Bug: Assumes Component Library Structure Without Verification

PDD-CLI generates E2E test selectors based on assumed component library DOM structure (like Shadcn slots) without verifying what the library actually renders.

**Why this matters:** Tests fail because PDD expects DOM structure that doesn't exist in the actual component library implementation.

## Concrete Example

For a page using card components:

```typescript
// PDD generated test (WRONG):
test('displays metric cards', async ({ page }) => {
  await page.goto('/dashboard');
  
  // Assumes Shadcn uses data-slot attributes
  const cards = page.locator('[data-slot="card"]');
  await expect(cards).toHaveCount(4);
});
```

But the component library renders different structure:

```typescript
// Card.tsx (actual Shadcn/component implementation)
export function Card({ children }: CardProps) {
  return (
    <article className="card">  {/* Plain <article>, no data-slot */}
      {children}
    </article>
  );
}
```

**What went wrong:** PDD assumed Shadcn components use `[data-slot]` attributes based on some UI libraries, but the actual library uses plain semantic HTML (`<article>`).

**Impact:** Test fails with `locator('[data-slot="card"]') not found (0 matches)`.

## Why PDD Makes This Mistake

PDD-CLI currently:
- Makes assumptions about component library internals
- Doesn't inspect actual rendered DOM
- Guesses at slot/attribute naming conventions

But it should:
1. Run the app and inspect actual DOM structure
2. Use Playwright codegen to discover real selectors
3. Prefer semantic HTML elements (`article`, `section`) over library-specific attributes

## How to Prevent This in PDD-CLI

**What PDD should do differently:**

1. **Generate UI first, then inspect:** Run the component in a browser and analyze actual DOM.

2. **Use Playwright codegen:** Let Playwright generate selectors from real interactions.

3. **Prefer semantic selectors:**
   ```typescript
   // Instead of assumed structure
   page.locator('[data-slot="card"]')
   
   // Use semantic HTML or data-testid
   page.getByRole('article')  // If cards are <article>
   page.getByTestId('metric-card')  // If testid added
   ```

4. **Document component library patterns:** Build knowledge base of how different libraries structure DOM.

**Example improvement:**
```
Current: "Test cards" → assume Shadcn structure → [data-slot="card"]
       → Generate test
       → Test fails (attribute doesn't exist)

Improved: "Test cards" → generate UI with data-testid="metric-card"
        → Run UI in browser
        → Inspect DOM: <article data-testid="metric-card">
        → Generate: page.getByTestId('metric-card')
        → Test passes
```

## Severity

**P2 - Medium Priority**

- **Frequency:** Medium - occurs when using component libraries PDD hasn't seen
- **Impact:** Test failures requiring manual selector fixes
- **Detectability:** High - fails immediately with clear errors
- **Prevention cost:** Medium - requires DOM inspection or codegen integration

## Category

`test-generation`

## Related Issues

- #416 - Exact string matches before seeing UI (same "assume first" problem)
- #419 - CSS utility class selectors (similar selector assumption issue)
- #420 - Text matching vs semantic (alternative selector strategy)

---

**For Contributors:** Discovered in `frontend/e2e/crm.spec.ts` where `[data-slot="card"]` selector failed, fixed in commit `34a651d5`.


Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PDD-CLI Bug: Assumes Component Library Structure Without Verification #574