Skip to content

Test plan enumeration of issues #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
crogger62 wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Test plan enumeration of issues #32

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions docs/test-plans/LES-177-test-plan.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# LES-177 Test Plan - Provide enumeration of issues

## Overview
The "enumeration of issues" feature lists Linear issues page-by-page, resolves
related entities (state, project, assignee), formats each issue line, and prints
summary counts. This plan focuses on verifying correct pagination, relation
handling, output formatting, and error propagation without calling the live
Linear API.

## Test Setup & Data
- Use mocked Linear SDK client responses (no network calls).
- Provide issues that exercise relation shapes:
- relation function returning a promise
- relation promise
- already-resolved object
- null/undefined relation
- Capture logger output for assertion.

## Unit Test Scenarios
### Relation resolution (`resolveRelation`)
| Scenario | Input | Expected Output |
| --- | --- | --- |
| Null/undefined relation | `null` / `undefined` | `null` |
| Relation function | `() => Promise.resolve(obj)` | `obj` |
| Promise relation | `Promise.resolve(obj)` | `obj` |
| Resolved object | `{ name: "Backlog" }` | same object |

### Issue line formatting (`formatIssueLine`)
| Scenario | Input | Expected Output |
| --- | --- | --- |
| Full detail | title + state + project + assignee | `" - Title (id: X) — [State] — project: P — assignee: A"` |
| Missing title | identifier provided | falls back to identifier |
| Missing title + identifier | none provided | uses `"<untitled>"` |
| Missing optional fields | blank state/project/assignee | omit those segments |

## Integration Test Scenarios
### Paginated listing (`listIssuesPaginated`)
- **Pagination**: multiple pages returned by the mocked client.
- Verify page headers (`Page N — X issue(s)`).
- Verify cursor usage (`after` passed on subsequent calls).
- Verify total count summary.
- **Relation resolution**: mix relation types in the same run.
- Ensure resolved names are used in output.
- **Error propagation**: client `issues()` rejects.
- Ensure the error surfaces to the caller (CLI handler logs and exits).

## Edge Cases
- Issue missing both title and identifier (prints `<untitled>`).
- Issue relations resolve to null (omit state/project/assignee segments).
- Empty page (0 issues) still prints a page header and returns total count.

## Error Scenarios
- Missing `LINEAR_API_KEY` in environment for CLI execution (fails fast).
- Linear client throws/rejects on `issues()` (error propagates to main handler).
- Relation function throws (error surfaces to caller).

## Integration Points to Validate
- Linear SDK pagination contract (`nodes`, `pageInfo`, `endCursor`).
- Relation resolution behavior for Linear SDK lazy relations.
- Logger/console output formatting.

## Performance Considerations
- Large number of pages: loop must terminate when `hasNextPage` is false.
- Default page size (50) should keep API calls bounded for large workspaces.
Loading