# Repository Overview

Welcome to the codebase. This repository is a collection of test fixtures and edge-case modules written in Java, designed to exercise code-analysis, linting, and documentation-generation tools. Rather than a production application, it contains carefully constructed scenarios — classes with dozens of fields, mixed-language comments, varied file headers, and tests scattered across non-standard directories — so that static-analysis pipelines can be validated against a rich set of real-world patterns. It runs on the Java platform and does not depend on any well-known external frameworks.

## Overview

This repository serves as a **test harness for code-tooling validation**. Each top-level module targets a specific family of edge cases that developers often encounter in large Java codebases:

- **Field descriptions** — how tools handle POJOs with minimal or no documentation.
- **Test code variety** — how tools discover and classify tests across JUnit 3, JUnit 4, and TestNG, including non-standard file locations.
- **File headers** — how tools parse, validate, and report on varied Java file-header styles (complete, partial, missing, license-style, and excessively long).
- **General edge cases** — empty classes, large DTOs, non-ASCII comments, and mixed naming conventions.

If you are building a linter, a code-quality tool, a documentation generator, or a code-migration utility, this repository gives you a shared suite of inputs to verify that your tool behaves correctly across diverse scenarios.

## Technology Stack

- **Language**: Java (all source files are `.java`)
- **Test frameworks present** (within test fixtures): JUnit 3 (`junit.framework.TestCase`), JUnit 4 (`org.junit.Test`), TestNG (`org.testng.annotations.Test`)
- **Build tool**: Not detected from imports; the directory structure suggests a Maven or Gradle layout with `src/main/java`, `src/test/java`, and custom directories.
- **No well-known frameworks** (Spring, Hibernate, etc.) were detected from import analysis. The code consists primarily of plain data classes and stubs.

## Architecture

The repository is organized into four top-level modules, each targeting a distinct area of edge-case testing:

```mermaid
flowchart TD
    root["Root Project"]
    p2["p2edgecases"]
    s1["story1fielddescription"]
    s2["story2testcode"]
    s4["story4fileheaders"]
    root --> p2
    root --> s1
    root --> s2
    root --> s4
    p2 --> p2svc["ProductService"]
    p2 --> p2other["Edge-case data classes"]
    s1 --> s1mix["Mixed"]
    s1 --> s1pa["PatternA"]
    s1 --> s1pb["PatternB"]
    s2 --> s2svc["OrderService"]
    s2 --> s2hlp["TestHelper"]
    s2 --> s2oth["Test fixture classes"]
    s4 --> s4ch["Crosslink"]
    s4 --> s4lh["LongHeader"]
    s4 --> s4ml["MitLicense"]
    s4 --> s4nh["NoHeader"]
    s4 --> s4nmp["NoModuleNoPurpose"]
    s4 --> s4ph["PartialHeader"]
    s4 --> s4wh["WithHeader"]
```

Each module is self-contained with no cross-module dependencies. Together they form a comprehensive test-bench for code analysis tools.

## Module Guide

### `p2edgecases` — General Edge-Cases

This module provides a collection of classes designed to test how code-analysis tools handle unusual class structures. It splits into two sub-groups:

- **Services** — Contains `ProductService`, a minimal data carrier with a single `productId` field and a `getProduct()` getter. This is intentionally simple and serves as a baseline example.
- **Other** — Contains the bulk of the edge-case classes: `A` (an empty class), `EucJpClass` (fields with Japanese comments), `LargeBusinessLabelClass` (50 fields), `LargeFieldMap` (a 10-field service DTO), `MixedLabelClass` and `PartialLabelEntity` (mixed labeling patterns), `MultiPattern` (ticket-numbered comment blocks), and `OrderProcessor` (a small order-creation stub). These classes test tooling limits around field counts, non-ASCII encoding, inconsistent naming, and empty class bodies.

The module uses a mix of English and Japanese comments throughout, intentionally, to verify that analysis tools handle non-ASCII content correctly.

### `story1fielddescription` — Field Description Patterns

This module defines three plain data classes that model distinct field patterns: `PatternA` (a single field with a Japanese comment), `PatternB` (two fields with Japanese comments for service interface identification), and `Mixed` (a composite that holds references to both `PatternA` and `PatternB`). The classes are simple POJOs with no behavior — just field declarations — and are designed to test how tools describe, detect, and report on field-level documentation (or the lack thereof).

### `story2testcode` — Test Code Detection

This is the most extensive module, structured around testing how code-analysis tools discover, classify, and report on test code. It is organized into three sub-groups:

- **Services** — Contains `OrderService`, a stub service class with an empty `run()` method. This is the service that test fixtures are conceptually designed to test, though none of the current tests actually exercise it.
- **Helpers** — Contains `TestHelper`, currently an empty placeholder class intended to become a shared utility for test setup and assertions.
- **Other** — Contains the core edge-case fixtures: `LegacyTest` (JUnit 3 `TestCase` inheritance), `RogueTestAnnotated` (JUnit 4 annotation in `src/main/java`), `TestNGTest` (TestNG annotation in `src/main/java`), `OrderServiceTest` (standard JUnit 4 test in `src/test/java`), `UnannotatedInTest` (file in test directory with no test annotations), `ImportOnlyTest` (orphaned import without usage), and `OrderServiceTestStandalone` (test in a custom `standalone/` source directory). Together, these seven classes cover every major edge case in test discovery: framework detection, annotation vs. naming-convention detection, non-standard file locations, and false-positive rejection.

The multi-framework usage (JUnit 3, JUnit 4, TestNG) and the deliberate scattering of test files across `src/main`, `src/test`, `src/utils`, and `standalone/` directories make this module a particularly comprehensive test of tool robustness.

### `story4fileheaders` — File Header Validation

This module provides seven Java classes, each with a different file-header configuration. It tests whether header-analysis tools can correctly classify and parse Java file headers. The classes cover the full spectrum:

- `WithHeader` — a complete, standard Japanese-style file header (the reference "correct" example)
- `Crosslink` — a complete header with additional version-tagged inline comments in the class body
- `PartialHeader` — has module name and purpose but an empty revision history
- `NoModuleNoPurpose` — missing the module name and purpose fields
- `NoHeader` — no header at all
- `MitLicense` — an MIT license header (distinguishing license text from module headers)
- `LongHeader` — a header with 250 version history entries, used as a stress test for tools that parse headers

The standard header format used here follows a Japanese project convention with three sections: program contents (`<プログラム内容>`), function overview (`<機能概要>`), and revision history (`<修正履歴>`).

## Getting Started

If you are new to this codebase and want to understand how the tools or analysis pipelines it feeds are likely to behave, here is a recommended reading order:

1. **Start with `story1fielddescription`** (`Mixed`, `PatternA`, `PatternB`). These are the smallest modules and give you a quick sense of the simple data-class pattern used throughout.
2. **Read `p2edgecases/Other`** next to see the variety of edge cases — from an empty class (`A`) to a 50-field DTO (`LargeBusinessLabelClass`). Pay special attention to `EucJpClass` and `LargeBusinessLabelClass` if you are concerned with non-ASCII encoding support.
3. **Explore `story2testcode/Other`** to understand the test discovery edge cases. This module alone covers JUnit 3, JUnit 4, and TestNG across four different source directories.
4. **Review `story4fileheaders`** to understand how file-header parsing works across six different header styles plus a license variant. Use `WithHeader` as your reference for a "correct" header.
5. **Dive into the sub-group pages** (`p2edgecases/Services`, `story2testcode/Helpers`, `story2testcode/Services`) for details on the few classes that contain actual methods.

Key classes to keep in mind:
- **`ProductService`** (`p2edgecases`) — the simplest service example
- **`OrderProcessor`** (`p2edgecases`) — the only class with a non-trivial method (`createOrder`)
- **`OrderService`** (`story2testcode`) — a stub service, the conceptual target of the test fixtures
- **`TestHelper`** (`story2testcode`) — an extension point for shared test utilities
- **`WithHeader`** (`story4fileheaders`) — the canonical reference for a correct file header