uttrflow / uttrflow/uttrflow-swift

Test that a dictation whose insertion times out ends as failed and keeps the words

Open Beginner friendly
#732 0 comments 0 reactions 0 assignees View on GitHub
area:dictation enhancement good first issue P1
Dominant language
Swift
Stars
4
Forks
17
Avg merge
3h 32m
Merged PRs (30d)
277

Description

## What happens

`Sources/UttrflowPipeline/DictationPipeline.swift:708-717`: insertion runs under `withStageTimeout(StageTimeout.quick, ...)`, which returns `nil` when the app being typed into doesn't answer in time. The `guard let attempt = inserted else { throw TextInsertionError.insertionRejected(description: "the application did not respond") }` branch has never run. `DictationStageTimeoutTests` covers a recogniser and a tidier that never answer, but not an inserter.

Measured on origin/main `26d7bc1` with `swift test --enable-code-coverage` (5,384 tests, all passing) and `xcrun llvm-cov export` over the test binary. The regions named below have an execution count of 0: no test runs them, so a change that breaks them passes `make verify`.

## Why it matters

The `catch` below it (line 730-733) hands the transcript to `fail(DictationFailure(error, transcript: text))`, so the interface can still offer the words. That's the only thing protecting a dictation when the app being typed into stops responding. If the `guard` is lost, a hung insertion could leave the pipeline stuck in `.inserting`, or end without the words.

## How to reproduce

Run `swift test --enable-code-coverage`, then `xcrun llvm-cov show -instr-profile .build/debug/codecov/default.profdata .build/debug/UttrflowPackageTests.xctest/Contents/MacOS/UttrflowPackageTests Sources/UttrflowPipeline/DictationPipeline.swift` and look for the `0` counts on the lines named above.

## Acceptance criteria

- A test in `DictationStageTimeoutTests` uses an inserter whose `insert` never returns, advances the clock past `StageTimeout.quick`, and expects the pipeline to reach `.failed` with a failure whose `transcript` is the dictated text.
- The same test starts a second dictation afterwards and expects it to begin (as `recoversForTheNextDictation` does for the recogniser).
- Each new test fails when the branch it covers is broken. Check this by hand before opening the PR: temporarily change the branch (flip the condition or return the other value), see the test fail, then restore it.

## Where to start

- `Tests/UttrflowPipelineTests/DictationStageTimeoutTests.swift`. Copy `transcriptionThatNeverAnswers` and swap in an inserter that suspends forever. The file already has `TimeoutTestInserter`, the `expire` helper and a manual clock.

Read `CONTRIBUTING.md` first. Iterate with `swift test --filter `, then run `make verify` before pushing. Only tests change; no product code needs to.

**Size:** S to M.

Contributor guide

Open the contributing guide

Research direction

Read CONTRIBUTING.md, then open Tests/UttrflowPipelineTests/DictationStageTimeoutTests.swift and review transcriptionThatNeverAnswers, TimeoutTestInserter, expire, and the manual clock. Run the focused suite with swift test --filter ; done means the inserter-timeout test reaches .failed with the transcript, a following dictation starts, and make verify passes.

Written by the indexing model from the issue text.

Assessment

Tech stack
swift
Domain
desktop, testing
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
88/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.