---
# (DD04) Business Logic — TestDetector.isTestClassName() [5 LOC]

| Field | Value |
|-------|-------|
| Fully Qualified Name | `com.optage.parser.TestDetector` |
| Layer | Utility |
| Module | `parser` (Package: `com.optage.parser`) |

## 1. Role

### TestDetector.isTestClassName()

This method determines whether a given Java class name should be treated as a test class based purely on its naming convention. It performs a lightweight classification step that supports the broader test-detection workflow in `TestDetector`, allowing the component to route obvious test-oriented class names into the test path without needing reflection, annotations, or package inspection. The method applies a simple routing pattern over three naming rules: names that end with `Test`, names that end with `Tests`, and names that begin with `Test`. Functionally, this is a shared utility rule rather than a domain transaction; its role is to normalize naming-based filtering so the caller can make a fast binary decision. Because the logic is string-prefix/suffix based, it is deterministic and has no side effects.

In the larger system, this method acts as the first gate in a broader detector flow. It helps separate production classes from unit/integration test classes using convention rather than metadata, which is a common pattern in code analysis or source parsing utilities. The method implements a small routing/dispatch pattern where one incoming class-name value is checked against multiple patterns and the first match resolves the decision to `true`. If none of the rules match, the method resolves to `false`, which means the class name is not considered test-like by the detector.

## 2. Processing Pattern (Detailed Business Logic)

```mermaid
flowchart TD
START(["isTestClassName(className)"])
COND1{"className endsWith Test?"}
COND2{"className endsWith Tests?"}
COND3{"className startsWith Test?"}
RET_TRUE(["Return true"])
RET_FALSE(["Return false"])
START --> COND1
COND1 -->|yes| RET_TRUE
COND1 -->|no| COND2
COND2 -->|yes| RET_TRUE
COND2 -->|no| COND3
COND3 -->|yes| RET_TRUE
COND3 -->|no| RET_FALSE
```

**CRITICAL — Constant Resolution:**
This method does not reference any external constants or constant files. All conditions are direct string-literal checks in the source code.

## 3. Parameter Analysis

| No | Parameter Name | Type | Business Description |
|----|---------------|------|---------------------|
| 1 | `className` | `String` | Java class name candidate being evaluated for test-class naming conventions. It can be any simple or fully qualified class-name text, but the method only inspects the text itself and does not consult annotations, inheritance, or package metadata. Values ending in `Test`, ending in `Tests`, or beginning with `Test` cause the method to return `true`; all other values return `false`. |

Instance fields / external state read at the end of the method: none. The method is pure and reads only its input argument.

## 4. CRUD Operations / Called Services

This method does not invoke CRUD-oriented service methods, database access, or repository operations. It only performs in-memory string evaluation and returns a boolean decision.

| CRUD | SC / CBS | SC Code | Entity / DB | Operation Description |
|------|----------|---------|-------------|-----------------------|
| - | - | - | - | No persistence or service calls are executed. |

## 5. Dependency Trace

### Pre-computed evidence from code analysis graph:

No screen/batch entry points found within 8 hops. Direct callers found: 14 methods.
Terminal operations from this method: -

The available code search shows only one internal caller inside the same class, where `isTestClassName(className)` is invoked from `TestDetector` itself. No external Java callers were found in the repository scan, so the method currently behaves as an internal helper used by its enclosing detector flow rather than as a cross-module API.

| # | Caller (Screen/Batch) | Call Chain (Full Path to this Method) | Terminal (SC / CRUD / Entity) |
|---|----------------------|--------------------------------------|-------------------------------|
| 1 | Utility:TestDetector | `TestDetector` -> `isTestClassName(className)` | `-` |

## 6. Per-Branch Detail Blocks

**Block 1** — [IF] `(className.endsWith("Test"))` (L55)

> Checks whether the class name matches the singular test-class suffix convention.

| # | Type | Code |
|---|------|------|
| 1 | RETURN | `return true;` |

**Block 2** — [ELSE-IF] `(className.endsWith("Tests"))` (L56)

> Checks whether the class name matches the plural test-class suffix convention.

| # | Type | Code |
|---|------|------|
| 1 | RETURN | `return true;` |

**Block 3** — [ELSE-IF] `(className.startsWith("Test"))` (L57)

> Checks whether the class name uses a test-first naming convention.

| # | Type | Code |
|---|------|------|
| 1 | RETURN | `return true;` |

**Block 4** — [ELSE] `(none of the naming rules matched)` (L55–59)

> The class name is not considered a test class by convention and the detector returns a negative result.

| # | Type | Code |
|---|------|------|
| 1 | RETURN | `return false;` |

## 7. Glossary

| Term | Type | Business Meaning |
|------|------|------------------|
| `className` | Field | Input class-name text evaluated by the detector. |
| `TestDetector` | Class | Utility component that classifies class names by test-oriented naming conventions. |
| `endsWith` | Technical operation | String suffix check used to detect naming patterns. |
| `startsWith` | Technical operation | String prefix check used to detect naming patterns. |
| `Test` | Naming convention | Prefix or suffix token commonly used to mark a class as test-related. |
| `Tests` | Naming convention | Plural suffix token commonly used to mark a class as test-related. |