Test coverage and confidence

Unit tests

src/test/unit/build.test.ts

• esbuild.js bundles every webview page script
• the F5 watch task runs esbuild and both type checkers

src/test/unit/modules.test.ts

• activating a module returns its API and registers it
• two modules cannot share an id, a settings namespace or an activity
• the optional extension points are collected from the modules that have them
• a problem report's environment facts are collected from the modules that have them
• a folder is owned when any module says it has data there; a module that throws claims nothing
• no folder: nothing; one folder: that folder (whatever the module says)
• several folders: the active editor wins, then the first folder with module data, then the first
• a folder the module cannot inspect is skipped
• the Retros module's activities are exactly the catalogue's retro activities

Integration tests

src/test/suite/extension.test.ts

• registers its commands
• ships a built script for each webview form
• resolves the repository and the retros folder
• the Retros view lists the retros

Unit tests

src/test/unit/release0110.test.ts

• both settings are in the Settings form

src/test/unit/settingsValues.test.ts

• trims text and falls back when nothing is left
• folders are relative: no leading or trailing slashes, a fallback when empty
• numbers must be whole and above zero
• a choice must be one of the allowed values
• a setting whose values a module supplies accepts only those, or nothing

Integration tests

src/test/suite/extension.test.ts

• Open Settings shows the Settings panel (#36)
• the Settings panel (#36) writes to the workspace or user settings, only what changed, and resets
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/release0110.test.ts

• only when the view is visible, nothing is open, and not already this window
• the setting values

Integration tests

src/test/suite/extension.test.ts

• 0.11.0: Home with nothing yet: both calls to action, the empty states, the curve, opening by itself (#61-#65)

Unit tests

src/test/unit/release0110.test.ts

• the history is the newest retro with the objective and its most recent review
• needs review: never assessed, not in the latest retro, or older than the threshold
• the default is two default periods
• daysBetween counts calendar days

Integration tests

src/test/suite/extension.test.ts

• 0.11.0: Home with objectives and retros: needs review, Assess, Continue and the next retro (#63, #64)

Unit tests

src/test/unit/release0110.test.ts

• no retros: today, then a period later
• continuous: the latest period end plus defaultPeriodDays
• overdue: today, so the period catches up
• dates that already have a retro are skipped; a bad period falls back to 14 days
• the saved stage wins; otherwise it is worked out from the content

Integration tests

src/test/suite/extension.test.ts

• 0.11.0: Home with objectives and retros: needs review, Assess, Continue and the next retro (#63, #64)
• 0.11.0: Home with nothing yet: both calls to action, the empty states, the curve, opening by itself (#61-#65)

Unit tests

src/test/unit/release0110.test.ts

• Darrel's four drawings, one per stage, in order
• each is theme-aware: currentColor ink, classes for the other colours, no inline styles (the CSP blocks them)
• goes into the page without its prolog and comments

Integration tests

src/test/suite/extension.test.ts

• 0.11.0: Home with nothing yet: both calls to action, the empty states, the curve, opening by itself (#61-#65)

Unit tests

src/test/unit/formModel.test.ts

• accepts valid values
• rejects an existing retro date
• rejects invalid and empty dates
• requires start <= end
• allows a one-day period, but not one that ends after the retro
• limits text lengths
• normaliseValues trims and removes line breaks
• suggestPeriod is the default window ending on the retro date
• describeContinuity flags an overlap or gap for the chosen start
• parses valid messages from the webview
• rejects malformed messages from the webview
• parseFormValues drops unknown properties
• parses messages from the extension

src/test/unit/naming-period.test.ts

• round-trips retro and feedback file names
• does not confuse retro, feedback and other files
• defaults to a fixed window of N days, inclusive, ending on the retro date
• finds the latest earlier retro, using its periodEnd when valid
• ignores retros on or after the new date (e.g. back-filling an old retro)
• reports continuity with the previous retro
• rejects nonsense period lengths
• periodLengthInDays handles daylight saving changes

src/test/unit/dates.test.ts

• isIsoDate accepts real dates and rejects impossible ones
• parseIsoDate trims and throws helpfully
• addDays crosses month, year and leap-day boundaries
• toIsoDate uses local time, not UTC
• isWithinPeriod is inclusive at both ends
• toLocalIsoTimestamp includes the local offset

Integration tests

src/test/suite/extension.test.ts

• creates a first retro via the New Retro command (form values as argument), without AI
• the New Retro form opens once, with defaults that follow the previous retro
• the form shows inline validation errors instead of creating a duplicate retro
• Cancel closes the form
• a second retro covers the gap since the first and carries its action items forward
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/feedbackTemplates.test.ts

• with no settings: the built-ins, defaulting to classic
• an unknown default or retro template falls back

Integration tests

src/test/suite/extension.test.ts

• the New Retro form opens once, with defaults that follow the previous retro
• a retro with the health check template has its own types, ratings and headings
• the Retro panel (#33): details, feedback done, and the Create GitHub Issues confirmation

Unit tests

src/test/unit/feedbackTemplates.test.ts

• the built-ins are valid, with unique ids and types
• with no settings: the built-ins, defaulting to classic
• the legacy feedbackTypes setting becomes the "custom" template and the default
• custom templates are validated, added, and replace built-ins with the same id
• an unknown default or retro template falls back
• a rating's section wins over the type's
• questions render as a Markdown list

src/test/unit/release040.test.ts

• the incident review has a root-cause type with an outline, and guidance for Copilot
• custom types can have a prompt; submitting the outline unchanged is rejected
• the built-in health check has an optional trend scale
• the trend is stored in the marker, survives edits, and old entries are unaffected
• summaries and prompts include the trend
• the form validates the trend and parses the new messages

Integration tests

src/test/suite/extension.test.ts

• a retro with the health check template has its own types, ratings and headings
• the health check records a trend per dimension

Unit tests

src/test/unit/templateSources.test.ts

• parseTemplateSources keeps known, unique sources in order
• parseSharedTemplateRef understands owner/repo, paths, refs, URLs and local folders
• isTemplateSourceFile picks template.json, retro.md and templates.json only
• loadTemplateSource reads folders, ids, layouts and the default, and reports problems
• precedence follows nabsConfidence.templateSources; personal settings win; the default comes from the sources
• templateToJson and blankTemplateJson round-trip through the validator
• the template.json schema matches the validator and the feedbackTemplates setting

Integration tests

src/test/suite/extension.test.ts

• feedback templates from the repo and a shared repository (fake GitHub), with caching and offline fallback (#14)

Unit tests

src/test/unit/templateSources.test.ts

• templateToJson and blankTemplateJson round-trip through the validator

Integration tests

src/test/suite/extension.test.ts

• feedback templates from the repo and a shared repository (fake GitHub), with caching and offline fallback (#14)
• the Settings panel (#36) writes to the workspace or user settings, only what changed, and resets
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/templateSources.test.ts

• precedence follows nabsConfidence.templateSources; personal settings win; the default comes from the sources

Integration tests

src/test/suite/extension.test.ts

• feedback templates from the repo and a shared repository (fake GitHub), with caching and offline fallback (#14)

Unit tests

src/test/unit/templateSources.test.ts

• the template.json schema matches the validator and the feedbackTemplates setting

Integration tests: none.

Unit tests

src/test/unit/document.test.ts

• the default template renders every placeholder
• custom templates can drop sections and keep unknown placeholders

Integration tests

src/test/suite/extension.test.ts

• creates a first retro via the New Retro command (form values as argument), without AI

Unit tests

src/test/unit/feedbackTypes.test.ts

• missing settings use the defaults without complaint
• valid custom types are used, with optional fields cleaned up
• invalid entries are skipped with a problem; nothing valid means the defaults
• the entry template must have {{text}} once and only known placeholders
• unknown type ids display as Other

src/test/unit/feedback.test.ts

• a custom template round-trips, and entries survive the template changing later
• the template is filled in one pass (text containing placeholders is left alone)

Integration tests

src/test/suite/extension.test.ts

• the legacy feedbackTypes setting becomes the "custom" template; the entry template comes from the settings

Unit tests

src/test/unit/feedbackFormModel.test.ts

• valid values have no errors
• reports each invalid field
• defaults to the newest in-progress retro, otherwise the newest
• parses messages from the webview strictly
• parses messages from the extension
• a rating is required when the retro has a rating scale
• in edit mode an entry may keep a type that is no longer in the template
• finds the template of the selected retro

src/test/unit/feedback.test.ts

• a new file has no entries (the format help is ignored) and lists the types
• the default format is the v0.1.0 heading, preceded by a marker
• appended entries round-trip through the parser
• a custom template round-trips, and entries survive the template changing later
• still reads hand-written v0.1.0 entries, including after marker entries
• keeps entries with unknown types (shown as "other"), skips empty ones, reports bad markers
• sanitises the author and text so the entry stays parseable
• anonymous entries are written as "Anonymous" and flagged in the marker
• the template is filled in one pass (text containing placeholders is left alone)
• renders grouped lists and counts by configured type

Integration tests

src/test/suite/extension.test.ts

• the Add Feedback form opens once, preselects the clicked retro, and supports "add another"
• a retro with the health check template has its own types, ratings and headings
• the health check records a trend per dimension
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/release040.test.ts

• person slugs make safe, stable file names
• a personal file says whose it is and parses like a shared one

Integration tests

src/test/suite/extension.test.ts

• per-person feedback files: each contributor writes their own file and marks it done

Unit tests

src/test/unit/release040.test.ts

• the done signal is set and cleared in the front matter, keeping the entries

Integration tests

src/test/suite/extension.test.ts

• per-person feedback files: each contributor writes their own file and marks it done
• the Retro panel (#33): details, feedback done, and the Create GitHub Issues confirmation
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/feedbackEdit.test.ts

• ids, ratings and edit times round-trip through the marker
• parsing records where each entry is
• updates one entry in place, keeping the others and the id
• refuses to overwrite an entry that changed since it was opened
• deletes one entry, tidying the blank lines
• hand-written (v0.1.0) entries can be edited by fingerprint and become marker entries
• keeps Windows line endings
• comments in the file do not shift the positions

Integration tests

src/test/suite/extension.test.ts

• the Retros view lists feedback entries, and the edit form updates and deletes them in place
• per-person feedback files: each contributor writes their own file and marks it done
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests: none.

Integration tests

src/test/suite/extension.test.ts

• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/retroProgress.test.ts

• Gather checks who is done, the feedback types and the lock
• counts entries across people and the shared file
• Gather for the facilitator: invite, nudge, then move on
• invitation and nudge texts
• "most people": everyone but one with three or more people

Integration tests

src/test/suite/extension.test.ts

• the Retro Dashboard (#41): stages, readiness, the soft gate and the feedback lock

Unit tests

src/test/unit/retroProgress.test.ts

• Gather for a participant: add feedback, mark done, then done
• facilitator by default when it is you, or nobody yet
• matches people by name or feedback file name

Integration tests

src/test/suite/extension.test.ts

• the Retro Dashboard (#41): stages, readiness, the soft gate and the feedback lock

Unit tests

src/test/unit/retroProgress.test.ts

• moving past Gather locks the feedback and lists what is still open
• going back to Gather (or Prepare) unlocks; moving within the locked stages leaves it
• applyMove writes the stage, who and when, and the lock
• Gather when feedback is locked: only the facilitator can go back

Integration tests

src/test/suite/extension.test.ts

• the Retro Dashboard (#41): stages, readiness, the soft gate and the feedback lock

Unit tests

src/test/unit/retroProgress.test.ts

• six stages in order, only Prepare and Gather guided in this version
• infers the stage of a retro without one
• the stage in the front matter wins over the inferred one

Integration tests

src/test/suite/extension.test.ts

• the Retro Dashboard (#41): stages, readiness, the soft gate and the feedback lock
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/retroProgress.test.ts

• Prepare is ready when the period, template, objectives and sharing are fine
• Prepare warns about gaps, unknown templates, no objectives and unpushed files
• Prepare warns when the period is missing
• Prepare: the facilitator chooses objectives, shares, then moves on

Integration tests

src/test/suite/extension.test.ts

• the Retro Dashboard (#41): stages, readiness, the soft gate and the feedback lock

Unit tests

src/test/unit/retroProgress.test.ts

• Gather for a participant: add feedback, mark done, then done
• facilitator by default when it is you, or nobody yet

Integration tests

src/test/suite/extension.test.ts

• the Retro Dashboard (#41): stages, readiness, the soft gate and the feedback lock

Unit tests

src/test/unit/retroProgress.test.ts

• the later stages have checklists too
• the later stages link out to the existing panels
• applyMove writes the stage, who and when, and the lock

Integration tests

src/test/suite/extension.test.ts

• the Retro Dashboard (#41): stages, readiness, the soft gate and the feedback lock

Unit tests

src/test/unit/panels.test.ts

• accepts only well-formed messages from a panel
• accepts only well-formed messages from the extension
• escapes everything from files and settings
• validates the details
• reads the details (TBC is no facilitator)
• writes only what changed, and renames the heading with the title
• leaves a heading that isn't the title alone
• renders bold, italic and code, and escapes everything else

src/test/unit/document.test.ts

• parses simple key/value pairs and quoted values
• handles Windows line endings
• returns the whole text as body when there is no front matter
• setFrontMatterValue updates, adds, and creates

src/test/unit/panelUpdates.test.ts

• splits a page into its regions, nested elements included
• sends only the regions that changed: an action in Feedback leaves Details alone
• reloads the page when its structure changes

Integration tests

src/test/suite/extension.test.ts

• the Retro panel (#33): details, feedback done, and the Create GitHub Issues confirmation
• the Retros view lists the retros
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/panels.test.ts

• validates the details
• writes only what changed, and renames the heading with the title

Integration tests

src/test/suite/extension.test.ts

• the Retro panel (#33): details, feedback done, and the Create GitHub Issues confirmation
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/panelUpdates.test.ts

• marks the page for unsaved changes: in-panel confirmation, restore notice, commit and discard buttons
• a draft is a field that differs from what the extension rendered
• unsaved input in section B survives an action in section A
• the action that saves a section drops its drafts, and only those
• a field changed elsewhere meanwhile keeps your version and is reported
• drafts of a field that is gone are dropped (e.g. an action item that became an issue)
• switching retro keeps the drafts for later, and brings them back
• reads back what setState stored, and ignores anything else

Integration tests

src/test/suite/extension.test.ts

• panels keep unsaved input (#37): only changed regions are sent, drafts survive actions, hiding and switching
• the Add Feedback form opens once, preselects the clicked retro, and supports "add another"
• the New Retro form opens once, with defaults that follow the previous retro

Unit tests

src/test/unit/insights.test.ts

• parses commits, numstat lines, binary files and renames
• normalises rename notation
• summarises authors, churn and hot files
• handles an empty log

src/test/unit/gitHistory.test.ts

• a very large history: thousands of commits and a vendor import of tens of thousands of files are read and summarised, only the period counts
• output over the buffer is a plain sentence about the period, not Node's buffer message
• a shallow clone says so and leaves out its oldest commit, which Git shows as adding every file
• merges: merge commits are not counted, the commits they bring in are, once
• unusual renames and names: moved to the root, into a new folder, spaces, non-ASCII, and a tab; each file is counted under its new path
• git's quoted paths and rename notation are read back to the real path

src/test/unit/document.test.ts

• reads and replaces only the block content
• returns undefined when markers are missing

Integration tests

src/test/suite/extension.test.ts

• creates a first retro via the New Retro command (form values as argument), without AI
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/insights.test.ts

• parses common remote URL formats
• builds search queries scoped to the repo and period
• classifies issues, PRs and discussions by what happened in the period
• extracts GraphQL error messages

Integration tests: none.

Unit tests

src/test/unit/feedback.test.ts

• renders grouped lists and counts by configured type

src/test/unit/release040.test.ts

• summaries and prompts include the trend

Integration tests

src/test/suite/extension.test.ts

• feedback can be added and summarised into the retro
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/insights.test.ts

• feedback prompt includes the feedback and the markers
• parses a well-formed model answer and rejects a malformed one

src/test/unit/release090.test.ts

• the summary prompts focus on the chosen objectives, with an "Outside focus" line
• without objectives the prompts are as before

src/test/unit/release040.test.ts

• summaries and prompts include the trend

Integration tests: none.

Unit tests: none.

Integration tests

src/test/suite/extension.test.ts

• feedback can be added and summarised into the retro
• feedback templates from the repo and a shared repository (fake GitHub), with caching and offline fallback (#14)

Unit tests

src/test/unit/releaseActivityLinks.test.ts

• "Release confidence since the last retro": start and end, the trend and the activities that moved, falls first
• the section says so when the period has no report, one report, or old reports without levels
• Retros adds the sections other modules provide to the Insights, and a section that fails is only left out

Integration tests

src/test/suite/extension.test.ts

• 0.14.4: an activity's level is an objective measure, the retro's Insights show release confidence since the last retro, and #act:<id> shows on the dashboard (#107)

Unit tests

src/test/unit/objectiveForm.test.ts

• validates the fields and criteria inline
• a new objective can't reuse another objective's id
• new criteria get the next free id; existing ids are kept
• a new objective file round-trips through the parser
• editing keeps other front matter keys and sections, and empties optional fields
• the file New Objective used to write still parses after editing
• a verdict must be chosen
• an override of the AI's verdict needs a reason
• agreeing with the AI, or no AI assessment, needs no reason
• evidence must not be empty

src/test/unit/objectives.test.ts

• parses an objective file: front matter, why, criteria with ids, done and automatic measures
• reports problems instead of failing: bad ids, missing titles, unknown metrics, bad dates
• slugs and new objective files

Integration tests

src/test/suite/extension.test.ts

• the Objective form (#34) creates and edits an objective, with its acceptance criteria
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/objectives.test.ts

• parses an objective issue: header lines, ids for this and other repositories, state
• merges sources in order (the first wins) and validates nabsConfidence.objectiveSources

src/test/unit/githubClient.test.ts

• objective issues: labelled issues are listed over pages without pull requests, with their state and assignees

Integration tests

src/test/suite/extension.test.ts

• objectives (#20): files and GitHub issues (fake), the chosen objectives in each new retro (0.9.0), linking, evidence, assessment and verdicts

Unit tests: none.

Integration tests

src/test/suite/extension.test.ts

• the Objective form (#34) creates and edits an objective, with its acceptance criteria
• every command opens its form or picker, whatever VS Code passes from its menus (#22)
• objectives (#20): files and GitHub issues (fake), the chosen objectives in each new retro (0.9.0), linking, evidence, assessment and verdicts

Unit tests

src/test/unit/release090.test.ts

• New Retro: the open objectives are ticked by default; achieved and dropped ones are listed unticked
• an existing retro: its own objectives are ticked, ones no longer in the sources are kept
• readSelection and cleanIds read ticked boxes and well-formed ids only
• changeSelection keeps existing regions verbatim, adds new ones and reports removals
• removing an objective with evidence, an assessment or a verdict needs confirmation
• New Retro form values: objectives are optional and cleaned; zero ticked gives a soft warning
• Dashboard: Prepare asks for at least one objective (a soft gate)

src/test/unit/objectives.test.ts

• the layout: the section is dropped when nothing is open, and added to older retros
• regions: set, missing markers, meta escaping

Integration tests

src/test/suite/extension.test.ts

• objectives (#20): files and GitHub issues (fake), the chosen objectives in each new retro (0.9.0), linking, evidence, assessment and verdicts
• every command opens its form or picker, whatever VS Code passes from its menus (#22)
• manual script section 14 (0.9.0, #53), steps 14.1 to 14.5 and 14.9 in order, as a person does them: New Retro, the dashboard, the Retro panel (#111)

Unit tests

src/test/unit/objectives.test.ts

• action items link to objectives with #obj:<id>
• feedback entries keep their objective; older fingerprints are unchanged
• the feedback form only accepts one of the retro objectives (or none)

Integration tests

src/test/suite/extension.test.ts

• objectives (#20): files and GitHub issues (fake), the chosen objectives in each new retro (0.9.0), linking, evidence, assessment and verdicts

Unit tests

src/test/unit/objectiveForm.test.ts

• evidence must not be empty

src/test/unit/objectives.test.ts

• computes automatic measures from the numbers we already collect
• renders the snapshot and reads it back (criteria, measures, evidence, links)

Integration tests

src/test/suite/extension.test.ts

• objectives (#20): files and GitHub issues (fake), the chosen objectives in each new retro (0.9.0), linking, evidence, assessment and verdicts
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/objectives.test.ts

• the assessment prompt and its answer
• records the AI assessment and the team verdict, with the override and its reason

Integration tests

src/test/suite/extension.test.ts

• every command opens its form or picker, whatever VS Code passes from its menus (#22)
• objectives (#20): files and GitHub issues (fake), the chosen objectives in each new retro (0.9.0), linking, evidence, assessment and verdicts

Unit tests

src/test/unit/objectiveForm.test.ts

• a verdict must be chosen
• an override of the AI's verdict needs a reason
• agreeing with the AI, or no AI assessment, needs no reason

src/test/unit/objectives.test.ts

• records the AI assessment and the team verdict, with the override and its reason

Integration tests

src/test/suite/extension.test.ts

• objectives (#20): files and GitHub issues (fake), the chosen objectives in each new retro (0.9.0), linking, evidence, assessment and verdicts
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests

src/test/unit/releaseRetroLink.test.ts

• the newest score in the period, in plain words with the release and commit
• the trend compares the newest score with the report before it
• releases in a row at 80 or more: the evidence for "80 or more for three releases"
• the Release module provides the measures through the core contract, reading the repository root it is given
• a measure with a dot in its id is accepted in a criterion; other names still are not
• the retro line for a release measure names the provider, the value and the period; one nobody provides says so
• the snapshot and the refresh fill in the release measures; the measures Retros has are unchanged
• Retros reads the providers it is given: every id gets a reading, a failing provider is only unavailable
• the objective form accepts a release measure and the file keeps it as (auto: <id>)

src/test/unit/releaseActivityLinks.test.ts

• a saved report lists every activity with its score and level, and it reads back
• a report saved before 0.14.4 has the levels in its table only, and they are read from there
• release.activity.<id>.level: the level (1 Low to 3 High) in the newest report of the period, with how it moved
• the activities of the catalogue are on offer, one measure each, and the family answers any of them

Integration tests

src/test/suite/extension.test.ts

• 0.14.1: an objective can use release confidence as its automatic measure, read from the saved release reports (#95)
• 0.14.4: an activity's level is an objective measure, the retro's Insights show release confidence since the last retro, and #act:<id> shows on the dashboard (#107)

Unit tests

src/test/unit/document.test.ts

• parses open and done task list items
• renders a follow-up section

src/test/unit/release040.test.ts

• parses mentions, due dates and issue links; ignores the placeholder
• the follow-up section shows the follow-through rate

Integration tests

src/test/suite/extension.test.ts

• a second retro covers the gap since the first and carries its action items forward

Unit tests

src/test/unit/release040.test.ts

• issue titles and bodies are clean
• links and ticks are written into the right line, keeping the rest

src/test/unit/githubClient.test.ts

• issues: the label is checked then created, the issue request has the documented shape, and the answer is read from its real shape
• issues: an assignee who cannot be assigned gives an unassigned issue, a label made meanwhile is fine, and other refusals say what GitHub said
• issues: the failures GitHub really answers with: no access, issues turned off, a revoked sign-in, the rate limit, an outage and a dropped connection
• not signed in: no request is made, and the message says to run the command again and sign in
• action item states: up to 50 issues per request, closed and open read, an issue that does not exist is left out
• explainFailure leaves other messages alone and only mentions the rate limit for the codes GitHub uses for it
• it reports a failure when GitHub disagrees, and skips the Discussion checks when there is no category
• read-only: it reads, never writes, and skips the writing checks
• with --write: it creates a label, two issues (closed again) and a Discussion with comments, and every check passes

Integration tests

src/test/suite/extension.test.ts

• action items become GitHub issues, are linked in the retro, and tick themselves off when closed
• the Retro panel (#33): details, feedback done, and the Create GitHub Issues confirmation
• every command opens its form or picker, whatever VS Code passes from its menus (#22)
• action items become real GitHub requests (a fake GitHub that checks the documented rules): labels, assignees that cannot be assigned, the rate limit midway, resuming, then the ticking off (#112)

Unit tests

src/test/unit/release040.test.ts

• links and ticks are written into the right line, keeping the rest

Integration tests

src/test/suite/extension.test.ts

• action items become GitHub issues, are linked in the retro, and tick themselves off when closed
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests: none.

Integration tests: none.

Unit tests

src/test/unit/releaseActivityLinks.test.ts

• #act:<id> links a feedback entry or an action item to an activity; the issue gets an activity:<id> label and a clean title

Integration tests

src/test/suite/extension.test.ts

• 0.14.4: an activity's level is an objective measure, the retro's Insights show release confidence since the last retro, and #act:<id> shows on the dashboard (#107)

Unit tests: none.

Integration tests

src/test/suite/extension.test.ts

• 0.10.0: archive a retro to a GitHub Discussion, resume without duplicates, then remove its files safely (#57-#60)

Unit tests

src/test/unit/release0100.test.ts

• the parts follow the stages: body, one comment per person, insights, objectives, decide, close
• the body says which objectives it addresses, the details, and who is done with counts
• a retro with no objectives says so
• each person's comment groups their feedback by type, with the objective
• insights, objectives (assessment, verdict, override reason), decide and close
• long parts are split under the limit, by paragraph, each with its own marker and a "continued" line
• splitMarkdown: paragraphs, then lines, then a hard cut; nothing is lost
• markers find what is already posted, for this retro only
• pendingParts skips the posted ones, in order
• progress lives in flat front matter keys
• helpers: title, person keys, table cells, placeholders and the upwards section
• the Archive record comment links the last commit and says how to restore

src/test/unit/githubClient.test.ts

• Discussions: the settings are read, and a repository without Discussions or without the category is told apart
• Discussions: creating one sends exactly what GitHub documents, and refusals (no category, too long, Discussions off) are explained
• Discussions: comments are added and read back over pages, a part is found by its marker over pages, and a deleted Discussion is undefined
• Discussions: the rate limit (as GraphQL reports it, with HTTP 200), a revoked sign-in and an outage stop the call with a message that says what to do
• with --write: it creates a label, two issues (closed again) and a Discussion with comments, and every check passes

Integration tests

src/test/suite/extension.test.ts

• archive and remove through the real GitHub client (a fake GitHub that checks the documented rules): the rate limit midway, resuming, a 70,000-character entry, a failed record comment, a failed git rm, a detached HEAD, and the restore command (#113, #114)
• 0.10.0: archive a retro to a GitHub Discussion, resume without duplicates, then remove its files safely (#57-#60)

Unit tests

src/test/unit/release0100.test.ts

• the Archive record comment links the last commit and says how to restore

Integration tests

src/test/suite/extension.test.ts

• archive and remove through the real GitHub client (a fake GitHub that checks the documented rules): the rate limit midway, resuming, a 70,000-character entry, a failed record comment, a failed git rm, a detached HEAD, and the restore command (#113, #114)
• 0.10.0: archive a retro to a GitHub Discussion, resume without duplicates, then remove its files safely (#57-#60)

Unit tests

src/test/unit/release0100.test.ts

• round-trips, newest first, one record per date
• bad JSON or bad entries are reported, not thrown
• @retro learns which retros were archived, and where

Integration tests

src/test/suite/extension.test.ts

• 0.10.0: archive a retro to a GitHub Discussion, resume without duplicates, then remove its files safely (#57-#60)

Unit tests

src/test/unit/release090.test.ts

• @retro /objectives: the prompt has only the chosen objectives, their evidence and verdicts

src/test/unit/release0100.test.ts

• @retro learns which retros were archived, and where

Integration tests: none.

Unit tests: none.

Integration tests

src/test/suite/extension.test.ts

• contributes its language model tools
• the language model tools return data from the workspace

Unit tests

src/test/unit/insights.test.ts

• builds search queries scoped to the repo and period
• classifies issues, PRs and discussions by what happened in the period

Integration tests

src/test/suite/extension.test.ts

• contributes its language model tools

Unit tests

src/test/unit/panelUpdates.test.ts

• the new messages are checked on both sides
• the environment lines end with each module's facts
• needs a title and what happened
• prefills GitHub's issue form (template, title and fields)
• keeps the link short enough, dropping the oldest log lines first
• copies the whole report as Markdown

Integration tests

src/test/suite/extension.test.ts

• Report a Problem (#38) is a form that opens a prefilled GitHub issue; the Output channel logs what happened
• every command opens its form or picker, whatever VS Code passes from its menus (#22)

Unit tests: none.

Integration tests

src/test/suite/extension.test.ts

• Report a Problem (#38) is a form that opens a prefilled GitHub issue; the Output channel logs what happened

Unit tests: none.

Integration tests

src/test/suite/extension.test.ts

• no command opened a Quick Pick or an input box (0.7.0: everything in forms)

Unit tests

src/test/unit/treeComposer.test.ts

• the roots are the modules' roots in order, and the nodes are passed through unwrapped
• children and tree items go back to the module that returned the node
• no modules: an empty tree; a node nobody returned has no children and no item
• a module that returns nothing, or a promise, is fine

Integration tests

src/test/suite/extension.test.ts

• the Retros view lists the retros
• the Retros view lists feedback entries, and the edit form updates and deletes them in place
• registers its commands

Unit tests

src/test/unit/releaseScore.test.ts

• the numbers come from catalogue.yml and are checked
• the worked example in the design reproduces: 75, 50, 39, 25 and 0
• with each older run counted as shared-only change, the score gives the matrix level for every combination
• a failing test blocks the activity: score 0, and the reason names the test
• open gaps take points off by severity, and never more than the maximum
• a hand-set cap holds the score down and says why; a cap never raises it
• no test at all: at most 39, even with a passed manual run
• real-world credit is scaled by the steps that passed and fresh, and is 0 without declared code
• tests with no result for this commit earn no credit; the explanation says to run them
• every activity explains itself in one sentence, with what would raise it
• what would raise it lists the most valuable change first and stops at the next level
• the release score is the mean weighted by impact: high 3, medium 2, low 1
• the gates are checked first: a failed test, a high-impact activity at Low, and an unowned change each hold the release
• without a gate: Go from 80, Go with known risks from 60 to 79, Hold below 60
• the verdict says in plain words what is holding the release back, most costly first

src/test/unit/releaseEvidence.test.ts

• fresh results and a run on an older version give the worked example: 25 + 25 + 25 = 75, Medium
• results for another commit earn nothing, and the notes say so
• a run that fails a step is the evidence for that step, and a failed test is a gate
• a run with a commit is compared with the code at that commit; without one, an older version counts as shared code changed, or as changed when strict
• missing integration results are named, and written gaps count only when asked to
• the report says the verdict, the score, what costs the most, the notes and every activity

Integration tests: none.

Unit tests

src/test/unit/releaseChanges.test.ts

• a file is the own code of the activities that list it (two can share a file), shared, ignored, or unowned
• a change to a file nobody owns is reported as unowned
• shared code affects the activities it says: all, a list, or (derive) those that reach the file
• derive without an import graph affects every activity: it may over-warn, it never under-warns
• a file that is both activity code and shared counts as owned by the activity
• name-status output: added, modified, deleted, and a rename counts as a delete and an add
• untracked files come from the status output and nothing else does
• the files changed since a tag, with their status
• the newest release tag, by version and not by name
• the head commit, clean; then dirty, with uncommitted and new files counted as changes

src/test/unit/releaseReport.test.ts

• a saved run record or report does not make the tree dirty, but any other change does

Integration tests: none.

Unit tests

src/test/unit/releaseResults.test.ts

• Mocha JSON becomes a result file: passed, failed and skipped per test, with the source file of each
• output that is not Mocha JSON, or has no tests, is reported in plain words
• a result file written out reads back the same, and a damaged one says what is wrong
• results count only for the same commit with a clean tree; another commit counts as not run
• the evidence for a list of tests counts passed ones and names failed ones; skipped and missing ones earn nothing
• a test with the same title in another file does not count
• stale results give no credit and say why
• every failed test of a fresh result is listed, whether or not an activity lists it
• a run that lists sections counts every step in them as passed; other steps are not covered
• a run that lists steps counts only those, with the result it gives
• the newest run that covers a step decides it, by date
• how fresh a run is: from its commit when it has one, else from its version
• is valid YAML that passes the run schema, whatever is in the text
• lists a section as run only when every step of it was run
• says what is wrong with the input instead of writing a bad record

Integration tests: none.

Unit tests

src/test/unit/releaseDashboard.test.ts

• the dashboard says the verdict and the score first, with the reason in words
• every activity is listed with its score, its level, where the score comes from and what would raise it
• a gate is shown as the reason the release is held
• the changed-code summary names the unowned files, and says so when there is no release tag to compare with
• anything that comes from the catalogue or a run is escaped
• no catalogue, or a broken one, says what is wrong and what to do instead of showing a score
• the tree and Home show one line: the verdict and the score
• the Release activities of the module are the activities of the catalogue group "release", and the settings and commands match package.json

Integration tests

src/test/suite/extension.test.ts

• 0.13.0: Release Confidence: no catalogue, then the dashboard, Home card, tree node, Run tests and Record a real-world run (#91, #93)

Unit tests

src/test/unit/releaseDashboard.test.ts

• the manual script's sections and steps are read from its headings and check boxes
• both step formats are read, and a line that is not a step is ignored
• the form has the run details, a choice for each section and one for each step, and escapes the script
• a step takes its own answer, else its section's; steps that were not run are left out

Integration tests

src/test/suite/extension.test.ts

• 0.13.0: Release Confidence: no catalogue, then the dashboard, Home card, tree node, Run tests and Record a real-world run (#91, #93)

Unit tests

src/test/unit/releaseReport.test.ts

• it states the verdict, the score, the commit and the tool, and explains the score in plain words
• every activity is in a table with its score, level, impact and why, and the inputs are listed
• a gate is the first thing said about why the release is held
• text from the catalogue cannot break the table or add HTML
• the badge is one line of text made now, with the score, the verdict, the date and the commit
• the file name says the version, the day and the commit; the body ends with a marker so it is never posted twice
• a body too long for a Discussion is shortened to the first thing that would raise each activity
• the front matter is the history of the score: it reads back, and anything else is not a report
• the saved reports are read oldest first, and a file that is not a report is skipped

Integration tests

src/test/suite/extension.test.ts

• 0.14.0: Release Report: Markdown, copy, save in the repository, and post to a Discussion only after the form is confirmed (#94)

Unit tests

src/test/unit/standaloneCatalogue.test.ts

• the XML reader handles entities, CDATA, attributes and self-closing elements, and refuses malformed files
• C# test names are the methods under [Fact] and [Theory], not the helpers
• a test class is found by its namespace and name, also nested, or by its simple name when only one file has it
• TRX results become test results by source file and method name; skipped, failed and unknown classes are handled
• JUnit XML results use the file attribute when there is one, else the class; failure and skipped are read
• method names drop arguments and namespaces; formats are told apart by extension and first element
• the version comes from package.json, a JSON field, or a pattern, and is ? when it is not there
• the bundled schemas are the files in catalogue/schema (run npm run gen:schemas after changing one)
• a repository with no npm, no schemas, no readiness and no scoring section can be checked, scored and recorded

src/test/unit/catalogueInit.test.ts

• init scaffolds a catalogue that passes check on a repository that has none, named after its package
• the scaffold can be scored straight away, and --product and --code decide the name and the files the first activity owns
• init never overwrites: when any file it would write exists, it writes nothing and says which
• gaps lists each written gap with its stable id, for one group or as JSON, and says so when there is no catalogue
• the npm package is the one bundle with a bin entry and no dependencies, and npm pack would publish exactly its files

Integration tests: none.

Unit tests

src/test/unit/catalogueGitHub.test.ts

• a tag is a marker comment or the Activities field of an issue form, and nothing else counts
• an activity gives the label of its group, a group gives its own, and an unknown id is reported and never labelled
• labels are planned from the tags: untagged items are never touched, labelled ones need nothing, typos are listed
• the labels command is a dry run unless --apply: it writes nothing, then labels issues and Discussions that have a tag and no others
• a gap has a stable id, and its issue carries the activity tag and the gap id
• a gap is matched to its issue by the marker, never the title; a closed gap is only reported
• gap-issues is a dry run unless --apply, refuses to open more than five without --limit, and never opens the same gap twice
• gap-issues opens the highest-impact gaps first, and --only chooses gaps by id and refuses ids it does not know
• an action item tagged #act:<id> makes an issue that carries the tag, so the labels script finds it
• GitHub is reached with a token or through the GitHub CLI; no token is read by the tool itself

Integration tests: none.