Test Driven Development (TDD) in Wikantik

Test Driven Development (TDD) is not just a practice in Wikantik; it is a mandatory mandate. As defined in GEMINI.md, every code change must be preceded or accompanied by a test case that verifies the intended behavior.

The TDD First Mandate

The core rule for all developers and AI agents is:

TDD First: Always write or update a test before fixing a bug or refactoring.

This ensures that:

Requirements are clear: Writing the test forces a clear definition of what "success" looks like.
Regressions are caught: The suite provides a safety net for future changes.
Design is improved: Code that is hard to test is usually code that is poorly designed.

The Testing Pyramid

1. Unit Tests (Fast & Isolated)

Unit tests target individual classes in isolation. In Wikantik, these are made possible by the use of Stubs.

Example: Testing a new MCP tool using StubPageManager rather than bootstrapping a full WikiEngine.
Target: 80% coverage for core logic in wikantik-api and wikantik-main.

2. Integration Tests (Component Interplay)

Found in the wikantik-it-tests module, these tests verify that multiple modules work together correctly.

Cargo: The build uses the Cargo plugin to launch a real Tomcat instance for testing.
PostgreSQL: Integration tests run against a real PostgreSQL instance with a scratch schema.

3. End-to-End Tests (User Flows)

Using Selenide, the project automates browser-based flows (login, page creation, admin actions) to ensure the React SPA and the Java backend are in sync.

TDD Workflow for AI Agents

Research: Understand the current behavior and existing tests.
Reproduction: Write a failing test case that demonstrates the bug or the missing feature.
Execution: Implement the minimal code change needed to make the test pass.
Validation: Run the full module test suite (mvn test -pl <module>) to ensure no regressions.