Repository navigation
trios/agent-server/apps/agent/entrypoints/sidepanel/index/ConnectAppCard.tsx exports one symbol and no test names any of them #1582
Description
trios/agent-server/apps/agent/entrypoints/sidepanel/index/ConnectAppCard.tsx exports one symbol and no test names any of them
Measured on origin/feat/queen-supervisor, the tree a bee clones:
$ git show origin/feat/queen-supervisor:trios/agent-server/apps/agent/entrypoints/sidepanel/index/ConnectAppCard.tsx | wc -l
224
exports: ConnectAppCard
searched: every *.test.ts under apps/server/tests, concatenated
found: none of these identifiers appears anywhere in that corpus
The weak version of this claim would be "there is no ConnectAppCard.tsx.test.ts",
and it would be worthless: 144 of 260 source files have no test of the same name,
and most of them are covered perfectly well by suites named after something else.
queen-tick.ts is exercised by a dozen queen-*.test.ts files and has no test
of its own name. So the question asked here is the stronger one - whether any
exported identifier of this module is mentioned anywhere in the test corpus at
all - and by that measure only nine modules in the repository qualify. This is
one of them.
Untested is not the same as broken. This asks for the first suite, not a rewrite:
the behaviour that already exists, pinned, so the next change to this file has
something to fail against.
User Scenarios & Testing
User Story 1 - The module's contract is pinned as it stands today (P1)
Acceptance Scenarios:
- Given each exported symbol,
When the suite runs,
Then at least one assertion exercises it, and the suite names the symbol
it is covering so a reader can map assertions to exports. - Given the module's behaviour as it is today,
When the suite runs against the unmodified source,
Then it passes. A first suite that requires changing the subject is a
redesign wearing a test's clothes. - Given a deliberately broken copy of the subject,
When the suite runs against it,
Then it fails. A suite never shown failing has not been tested. - Given the suite,
When it runs,
Then it needs no network, no database and no container.
User Story 2 - What could not be pinned is named (P2)
Acceptance Scenarios:
- Given an export whose behaviour cannot be exercised without a live
dependency,
When the suite is read,
Then that export is listed in a comment with the dependency that blocked
it, rather than silently omitted. An untested export inside a file that now
looks tested is worse than one in a file that plainly is not.
Requirements
- FR-001: The subject MUST NOT be modified. If a symbol cannot be tested without changing it, say so in the comment required above and leave it.
- FR-002: The suite MUST run under
bun testin an existing group and MUST NOT require a database, a container or the network. - FR-003: Every assertion MUST test observable behaviour, not the shape of the implementation. A test that asserts a function calls another function pins the code rather than the contract.
- FR-004: The bee MUST demonstrate the suite failing against a deliberately broken copy before showing it passing, and quote both runs.
- FR-005: No existing test may be modified or weakened.
Success Criteria
bun test trios/agent-server/apps/agent/entrypoints/sidepanel/index/ConnectAppCard.test.tspasses, and its raw stdout is quoted in the report, unedited and unsummarised.- Every one of the 1 exported symbols is either exercised by an assertion or listed in a comment with the dependency that prevented it; the report quotes
grep -c 'it(' trios/agent-server/apps/agent/entrypoints/sidepanel/index/ConnectAppCard.test.tsand its raw output, and the two counts sum to 1. The command MUST NOT name or enumerate the specific items it counts. - A failing run against a deliberately broken copy of the subject is quoted, raw and unedited, alongside the passing one - a suite never shown failing has not been tested.
git diff --name-onlyis quoted raw and does not listtrios/agent-server/apps/agent/entrypoints/sidepanel/index/ConnectAppCard.tsx.- The suite registers under a describe named
ConnectAppCardTsxContract; that identifier appears nowhere in the tree today.
Boundary
trios/agent-server/apps/agent/entrypoints/sidepanel/index/ConnectAppCard.test.ts
Activity
Merge pull request #2029 from gHashTag/zcode-mbp/tests-1582-connect-a…
dmitrii-f-t27 commentedon Oct 15, 2026
Closed by PR #2029 (merge
1e18ebccfa): the first suite forapps/agent/entrypoints/sidepanel/index/ConnectAppCard.tsx.The pin (
describe ConnectAppCardTsxContract, the only export): the choosing card answers the connect heading with its reason, the connect button naming the app and the manual button; the resolved card answers the suggested note with the app's name. The seams are stubbed in the forms this group already carries (the MCP store in its live-proxy module form, the chat-session context, idle mutations, the declined-apps stand-in, the no-op track), the api-key dialog staying real and closed. The oauth round trip, the api-key submission, the manual decline and the completion messages live in handlers needing a live document - per User Story 2.Criteria:
grep -c 'it(' …ConnectAppCard.test.ts= 1; 1 exercised + 0 blocked = 1 ✓git diff --name-onlylists only…ConnectAppCard.test.ts(subject untouched) ✓0 pass / 1 fail; restored →1 pass / 0 fail / 6 expect()✓Gates: local agent group
404 pass / 3 fail / 407 tests(the 3 = the pre-existing port-helper noise, unchanged from baseline); Biome 0; Typecheck 0 errors / 0 mentions. CI on the merged SHA: all checks green - Tests/* (agent and pglive included, no reruns), Typecheck, Biome.