Conversation
Add support for moving issues between projects using Jira Cloud bulk move API: - `jtk issues move <issue-key>... --to-project <project>` - Move issues - `jtk issues move-status <task-id>` - Check async task status Features: - Async operation with polling (--wait default, --no-wait for immediate return) - Automatic issue type matching or explicit --to-type flag - Notification control via --notify flag (default: true) - Max 1000 issues per request Note: This feature is only available on Jira Cloud, not Server/Data Center. Closes #36 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
TDD Assessment: PR #51 -
|
| Function | Coverage | Notes |
|---|---|---|
BuildMoveRequest |
Good | Tests comma-separated target key format, notify flag |
MoveIssues |
Good | Tests POST request, URL path, request body parsing |
GetMoveTaskStatus |
Good | Tests success, empty ID validation, partial failures |
GetProjectIssueTypes |
Good | Tests success, empty project validation |
GetProjectStatuses |
Good | Tests success, empty project validation |
The API tests use httptest.NewServer to mock Jira responses, which is the standard pattern in this codebase. They verify:
- Correct HTTP methods and URL paths
- Request body serialization
- Response deserialization
- Input validation (empty IDs, empty project keys)
- Partial failure scenarios (some issues fail to move)
What's NOT Tested (internal/cmd/issues/move.go - 253 lines, 0 tests)
The runMove function contains significant business logic that is untested:
-
Issue count validation (line 68-69)
if len(issueKeys) > 1000- boundary condition not tested
-
Issue type resolution (lines 87-121)
- When
--to-typeis empty, fetches source issue type and matches by name - Falls back to first non-subtask type if no match
- Case-insensitive matching via
strings.EqualFold
- When
-
Error handling for Jira Server/DC (lines 141-144)
- Detects 404 errors and provides Cloud-only guidance
-
Async polling loop (lines 157-191)
- Status transitions: ENQUEUED -> RUNNING -> COMPLETE/FAILED/CANCELLED
- Partial failure handling (some issues move, some don't)
- Unknown status handling
-
runMoveStatusfunction (lines 210-252)- Table vs JSON output formatting
- Success/failure result display
Comparable Test Coverage in Codebase
Looking at internal/cmd/issues/types_test.go, similar commands in this codebase have tests that:
- Mock the HTTP server
- Inject the client via
opts.SetAPIClient(client) - Test success paths, error paths, and edge cases
- Test both table and JSON output modes
Recommendation
The current coverage is acceptable for merging, but adding command-level tests would bring this PR in line with existing patterns. Suggested test cases if you want to match existing coverage standards:
TestRunMove_ExceedsIssueLimit- verify 1001 issues returns errorTestRunMove_IssueTypeMatchesByName- verify case-insensitive type matchingTestRunMove_FallbackToFirstNonSubtask- when source type doesn't exist in targetTestRunMove_NoWait- returns task ID immediatelyTestRunMove_PartialFailure- some issues fail, some succeedTestRunMoveStatus_JSONOutput- verify JSON serialization
The API layer tests are solid. The gap is in the CLI command layer, which has non-trivial logic that could benefit from direct testing. That said, this is consistent with many other commands in the codebase that also lack command-level tests, so it's a pre-existing pattern rather than a regression.
Assessment generated by Claude Code
Summary
jtk issues move <issue-key>... --to-project <project>to move issues between projectsjtk issues move-status <task-id>to check async task status--to-type,--notify,--waitflagsTest plan
Closes #36
🤖 Generated with Claude Code