A test run produces two things you care about: which tests failed, and where. A wall of terminal output gives you the first and makes you hunt for the second. LingCode's Test Results tab gives you both at once — a filterable pass/fail list where each failure's stack frames are clickable links straight to the source line, plus a coverage toggle showing which lines your tests actually exercised. This page is how to read it.
Find it in the bottom panel as Test Results (the seal-with-checkmark icon). If you want the lay of the land first, the bottom panel overview places it among the other eight tabs.
Before you've run anything, the tab shows a placeholder: "No test results yet" with the hint "Run tests from the Test Explorer". Kick off a run from the Test Explorer and the tab fills with one row per test as results come in.
Across the top is a filter bar with four buttons — All, Passed, Failed, Skipped — each showing a live count (green for passed, red for failed, orange for skipped). The selected filter is shown in a heavier weight, and clicking it again toggles it off. On the right, a summary line restates the totals (e.g. "5 passed, 2 failed"). When a run goes red, click Failed and you've hidden every passing test in one click.
Each row carries a status icon (checkmark for passed, ✕ for failed, dash for skipped), the test name in monospace, and the duration in milliseconds on the right. A passing test is just those three. A failing test adds its failure message beneath — the assertion that blew up and the stack trace.
This is the part that saves time. Inside a failure message, any stack frame that points at a file in your workspace — something like /path/to/MyTests.swift:42:15 — is rendered as a blue underlined link. Click it and the editor jumps to that exact file, line, and column. There's also a jump arrow on the right of the row that takes you to the first resolvable frame in one click.
Frames that don't resolve to a workspace file (system framework internals, for instance) stay as plain grey text with a "File not found in workspace" tooltip, so you're never sent chasing a path that isn't yours. Under the hood the jump reuses the same source-reveal mechanism the debugger uses, so it lands you precisely where execution failed.
On the right of the filter bar is a code coverage button — an eye icon that toggles between "shown" (accent-colored, with an open eye) and "hidden" (a slashed eye). Turn it on and the tab surfaces the coverage summary for the last run, overlaying which lines your tests actually executed. Use it to answer the question the green checkmarks don't: did my tests even run the code I think they did? A test can pass while never touching the branch you meant to cover.