TDD Skill — BitcoinAddressFinder

TDD Skill — BitcoinAddressFinder

This skill documents **test-driven development practices and refactoring patterns** used in the BitcoinAddressFinder project. Apply these rules alongside `TEST_WRITING_GUIDE.md`, `CODE_WRITING_GUIDE.md`, and `CLAUDE.md`.

---

1. Extract Static Methods Into a Non-Static Helper Class

Motivation

Static utility methods embedded in a domain class (e.g. `AddressTxtLine`) are hard to unit-test in isolation and cannot be mocked or injected. Extracting them into a dedicated, non-static helper class (e.g. `Bech32Helper`) allows:

• Direct, focused unit tests for each method without going through the owning class.
• Easier mocking when a consumer needs to stub the helper in its own tests.
• A single, named home for related utilities — consistent with the BitHelper pattern already established in the project.

Pattern

**Before:** static method buried in a larger class

// AddressTxtLine.java — hard to test in isolation
private static byte[] decodeBech32CharsetToValues(String base32String) { ... }

**After:** non-static method on a dedicated helper class

// Bech32Helper.java — small, focused, testable
public class Bech32Helper {
    public byte[] decodeBech32CharsetToValues(String base32String) { ... }
}

The owning class holds an instance field and delegates:

// AddressTxtLine.java
Bech32Helper bech32Helper = new Bech32Helper();
// ...
byte[] payload = bech32Helper.extractPKHFromBitcoinCashAddress(address);

Naming Conventions

• Helper class names end with Helper (e.g. BitHelper, Bech32Helper).
• The corresponding test class ends with HelperTest (e.g. BitHelperTest, Bech32HelperTest).
• Public constants on the helper follow public static final with a Javadoc comment as required by CODE_WRITING_GUIDE.md.

When to Apply

Apply this extraction when:

1. A class contains ≥ 2 closely related static (or effectively-static) methods that operate on the same concept.
2. Those methods are not yet tested directly — their test coverage is indirect, piggybacking on a higher-level test class.
3. The methods are stable enough that the refactoring does not break any public API contract.

Do **not** apply this extraction for one-off utility methods that logically belong to their host class and have no reuse outside it.

Accompanying Test Migration

When the extracted methods already have tests in the original test class (e.g. `AddressTxtLineTest`), **move** those tests to the new test class:

1. Copy the test methods verbatim into Test.java.
2. Delete them from the original test class.
3. Clean up any imports in the original test class that are no longer needed after the removal.
4. Add new tests for any methods that were not yet directly covered (see TEST_WRITING_GUIDE.md for the required test structure).

---

2. Test Class for a Helper — Required Coverage

Every hel