ワンクリックで
uw-analyze-unit-tests
Use when analyzing unit test coverage, patterns, and test code for isolated component testing
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when analyzing unit test coverage, patterns, and test code for isolated component testing
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use after unwind:uw-plan to EXECUTE the rebuild — interview the user about scope/order/target, dispatch technology-agnostic per-layer builder agents that reproduce the [MUST] contracts in the target stack, hold rebuild state in a local file, and maintain a source→target verification graph that measures completeness. Supports a loop-until-verified mode.
Use to visually explore the rebuild knowledge graph. Builds and launches the Unwind dashboard (React + React Flow + ELK) pointed at docs/unwind/rebuild-graph.json with coverage, priority, and contract views.
Optional. Publish the Unwind dashboard to the scanned project's GitHub Pages gh-pages branch so it's viewable at https://<owner>.github.io/<repo>/unwind/. Builds the dashboard at the correct sub-path and commits it into an `unwind/` subdir — never blatting an existing gh-pages branch. Confirms the target, then pushes.
Use when dispatched by unwind:uw-build to rebuild ONE layer/slice of a codebase in the target stack. Technology-agnostic builder that reproduces the layer's [MUST] contracts (API surface, data model, business rules) as idiomatic target-stack code and records the source→target mapping for verification.
Use when starting any reverse engineering task - establishes how to find and use Unwind skills for codebase analysis, service mapping, and documentation
Use after layer analysis is complete to interview the user about the rebuild strategy (target stack, what to keep vs rebuild, phasing, risk) and generate a data-grounded REBUILD-PLAN.md that records those decisions.
| name | uw-analyze-unit-tests |
| description | Use when analyzing unit test coverage, patterns, and test code for isolated component testing |
| allowed-tools | ["Read","Grep","Glob","Bash(mkdir:*, ls:*)","Write(docs/unwind/**)","Edit(docs/unwind/**)"] |
Output: docs/unwind/layers/unit-tests/ (folder with index.md + section files)
Principles: See analysis-principles.md - completeness, machine-readable, link to source, no commentary, incremental writes.
docs/unwind/layers/unit-tests/
├── index.md # Test summary, coverage overview
├── service-tests.md # Service layer tests
├── domain-tests.md # Domain/entity tests
├── utilities.md # Test utilities, factories
└── coverage-gaps.md # Classes without tests
For large codebases (50+ test files), split by domain:
docs/unwind/layers/unit-tests/
├── index.md
├── users-tests.md
├── orders-tests.md
└── ...
Step 1: Setup
mkdir -p docs/unwind/layers/unit-tests/
Write initial index.md:
# Unit Tests
## Sections
- [Service Tests](service-tests.md) - _pending_
- [Domain Tests](domain-tests.md) - _pending_
- [Test Utilities](utilities.md) - _pending_
- [Coverage Gaps](coverage-gaps.md) - _pending_
## Summary
_Analysis in progress..._
Step 2: Analyze and write service-tests.md
service-tests.md immediatelyindex.mdStep 3: Analyze and write domain-tests.md
domain-tests.md immediatelyindex.mdStep 4: Analyze and write utilities.md
utilities.md immediatelyindex.mdStep 5: Analyze and write coverage-gaps.md
coverage-gaps.md immediatelyindex.mdStep 6: Finalize index.md Add coverage summary table
# Unit Tests
## Configuration
[pom.xml test dependencies](https://github.com/owner/repo/blob/main/pom.xml#L50-L70)
```xml
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.9.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>5.0.0</version>
<scope>test</scope>
</dependency>
| Layer | Classes | Tested | Coverage |
|---|---|---|---|
| Service | 12 | 10 | 83% |
| Domain | 8 | 8 | 100% |
| Repository | 6 | 4 | 67% |
@ExtendWith(MockitoExtension.class)
class UserServiceTest {
@Mock
private UserRepository userRepository;
@Mock
private PasswordEncoder passwordEncoder;
@InjectMocks
private UserService userService;
@Test
void createUser_success() {
CreateUserRequest request = new CreateUserRequest("test@example.com", "password", "Test");
when(userRepository.existsByEmail(request.email())).thenReturn(false);
when(passwordEncoder.encode(request.password())).thenReturn("encoded");
when(userRepository.save(any())).thenAnswer(inv -> inv.getArgument(0));
User result = userService.createUser(request);
assertThat(result.getEmail()).isEqualTo("test@example.com");
verify(userRepository).save(any());
}
@Test
void createUser_duplicateEmail_throws() {
CreateUserRequest request = new CreateUserRequest("existing@example.com", "password", "Test");
when(userRepository.existsByEmail(request.email())).thenReturn(true);
assertThrows(DuplicateEmailException.class, () -> userService.createUser(request));
}
}
Tests: createUser_success, createUser_duplicateEmail_throws, getUser_success, getUser_notFound_throws
[Continue for ALL test classes...]
class UserTest {
@Test
void suspend_activeUser_setsSuspended() {
User user = new User("test@example.com", "hash");
user.setStatus(UserStatus.ACTIVE);
user.suspend();
assertThat(user.getStatus()).isEqualTo(UserStatus.SUSPENDED);
}
@Test
void suspend_deletedUser_throws() {
User user = new User("test@example.com", "hash");
user.setStatus(UserStatus.DELETED);
assertThrows(IllegalStateException.class, () -> user.suspend());
}
}
public class TestDataFactory {
public static User createUser() {
return new User("test@example.com", "encodedPassword");
}
public static Order createOrder(User user) {
Order order = new Order(user);
order.addItem(createProduct(), 2);
return order;
}
}
Classes without unit tests:
PaymentServiceNotificationServiceLegacyOrderAdapter
## Refresh Mode
If `docs/unwind/layers/unit-tests/` exists, compare current state and add `## Changes Since Last Review` section to `index.md`.