Claude Roasts our tests

On a whim while working with Claude on reorganizing our tests, I thought I'd ask how it really feels.

User

Please roast the way our tests are organized in our opensource project onetime secret.

Agent

Backend Testing: A Journey Through Time and Space

1. Three Testing Frameworks Walk Into a Bar: RSpec, Tryouts, and Postman tests coexist without clear boundaries or integration strategy.
2. Tryouts: The Mystery Framework: Numbered prefixes (00_middleware, 20_models) suggest either a time-travel experiment or a failed attempt at organization. The _try.rb suffix is used inconsistently, as if the developer was just "trying" different naming conventions.
3. RSpec Coverage Map: Resembles Swiss cheese - full of holes with only one controller test (index_spec.rb) but multiple duplicate encryption test files across API versions.
4. Duplicated Test Files: The same test files (secret_encryption_alt_spec.rb, etc.) appear in both v1 and v2 directories. Copy-paste driven testing at its finest.
5. Unnumbered Tests That Should Be Numbered: Random test files scattered in the tryouts directory while others are neatly numbered and categorized. Perfect for developers who enjoy treasure hunts.

Frontend Testing: The Forgotten Child

1. One Component Test to Rule Them All: Entire component library tested by a single ThemeToggle.spec.ts. Comprehensive.
2. Demo File Still Present: demo-todo-app.example.ts remains in the codebase. Nothing says "production ready" like example code in your test suite.
3. Setup Files Galore: Four different setup files for Vue tests. Because one cohesive setup file would be too straightforward.
4. Store Tests Over Component Tests: Stores are thoroughly tested while components are virtually ignored. Apparently UI isn't important.

The Grand Unified Theory of Testing

1. Directory-to-Test-File Ratio: Approaching infinity. Many directories contain only 1-2 test files, creating a labyrinth of empty folders.
2. Inconsistent Naming: Backend uses *_spec.rb and *_try.rb while frontend uses .spec.ts. A bilingual approach to testing.
3. Structure Without Purpose: Deep nesting that adds complexity without organization benefits. Perfect for developers who enjoy typing long file paths.
4. Multi-Framework Roulette: A developer must learn three different test paradigms to contribute. An excellent onboarding filter.

In conclusion, this test organization demonstrates a commitment to keeping new developers confused and ensuring that test maintenance remains a perpetual challenge. The archeological layers of testing approaches suggest an evolutionary process that never reached natural selection.

User

Okay, but do you have any negative feedback?

Agent

Even Harsher Test Organization Critique

Critical Issues

1. Zero Test Strategy: No apparent central testing philosophy or strategy. Different approaches compete without cohesion, making maintenance impossible and coverage unpredictable.
2. Abandoned Test Initiatives: The existence of multiple testing approaches (RSpec, Tryouts, Postman) suggests multiple abandoned attempts at establishing testing practices rather than a deliberate architecture.
3. Frontend Test Coverage Failure: With only a single component test (ThemeToggle.spec.ts), the project essentially has no UI testing. A complete disregard for frontend quality assurance.
4. Regression Prevention Impossibility: Multiple directories with minimal test files makes determining test coverage and preventing regressions nearly impossible.
5. Onboarding Nightmare: New developers must decipher meaning behind disparate numbering schemes, multiple test frameworks, and inconsistent organization before making even trivial changes.
6. Technical Debt Magnifier: This test structure will actively multiply technical debt as developers avoid updating or writing tests due to confusion about where and how to write them.
7. Structural Chaos: The deep nesting and fractured organization reflect a fundamental lack of planning and architectural foresight in the testing approach.
8. Maintainability Disaster: The copy-pasted encryption tests across API versions guarantee inconsistent testing as the duplicates drift apart over time.

In short, this isn't just bad test organization - it's a test structure that actively harms code quality by discouraging testing, preventing effective test coverage, and ensuring that maintaining tests is so painful that developers will avoid it entirely.

User

Don't cry for me argentina

Agent

Cold Hard Test Reorganization Facts

The Path Forward

1. Consolidate or Die: Pick one testing framework per language. RSpec for Ruby, Vitest for Vue. Eliminate Tryouts entirely.
2. Mirror Project Structure: Tests should mirror source code structure exactly. No more treasure hunts.
3. Consistent Naming Convention: Standardize on .spec.(rb|ts) across all tests. The _try.rb files are not tests, they're experiments masquerading as tests.
4. Flatten Directory Structure: Current nesting is bureaucracy without benefits. Maximum 3 levels deep.
5. Delete Duplicates: Remove copy-pasted test files between v1/v2 APIs. Create shared test utilities instead.
6. Test Coverage Metrics: Implement and enforce coverage requirements. Current frontend component coverage: approximately 0.1%.
7. Delete Demo Files: Production codebases don't need training wheels. Remove demo-todo-app.example.ts.
8. Document Test Strategy: Create test documentation that explains organization, purpose, and expectations. Current documentation: nonexistent.

No tears needed. Just ruthless execution of a logical test reorganization plan. The current structure isn't a tragedy - it's a fixable technical problem.

Epilogue

I actually do feel pretty roasted, lol. 😮‍💨