In T11.1 you wrote six issues. This lesson works through the first two: assessment finished and support chat finished. Both features have existed since T2 and T5, so little is newly built here. What's new is that in the end every acceptance criterion from the issue has a test that proves it, and that the pull request names the numbers that show how well the feature works with a real model.
The lesson follows the path you know from K2: one branch per issue, commits, a pull request with a review. In between stand three tools that you reuse for all AI features:
- a host for the acceptance that wires the Kladde like the web app, only with a fake model at the very bottom,
- acceptance tests whose names are the criteria of the issue,
- a trait on every test class with which you start the acceptance of a single feature.
From criterion to test name
An acceptance criterion from the column "what the code guarantees" is a sentence that is true or false. A good test name is the same sentence in English, in PascalCase. For issue 1, the mapping looks like this:
| Criterion from issue 1 | Test |
|---|---|
| Every stored assessment names prompt version and model, even one that is "not assessed". | EveryOutcomeNamesItsPromptVersionAndModel |
| A broken answer is asked for again exactly once, after that the tender is "not assessed" with a reason. | ABrokenAnswerIsAskedForAgainExactlyOnce |
Every call counts in the cost meter under tender-assessment, the repeat too. |
EveryCallCountsUnderTheFeatureAndIntoTheMonth |
| The tender text reaches the model only inside the fence. | TheTenderTextReachesTheModelOnlyInsideTheFence |
And for issue 2:
| Criterion from issue 2 | Test |
|---|---|
| Without a hit above the threshold, the chat asks no model. | WithoutAHitTheChatAsksNoModel |
| An invented source never becomes a link. | AnInventedSourceNeverBecomesALink |
| Without a valid source, the answer is not shown. | WithoutAValidSourceTheAnswerIsNotShown |
Every call counts under support-chat. |
EveryCallCountsUnderTheFeature |
| Above every answer stands "You are chatting with an AI", in the language of the page. | EveryLanguageOfTheChatHasTheAiNotice |
Many of these sentences you already checked once in T2 to T6, as a single test of one class: TenderAssessorTests from T2.3 assembles the
assessment service itself, and SupportChatTests from T5 does the same. Such a test proves that the class works correctly. It doesn't
prove that the Kladde plugs it together correctly: that the assessment runs through the meter, that the cap from T10.3 receives the costs,
that the container really holds the prompt version you mean. That is exactly what an acceptance criterion asks. An acceptance test
therefore gets the feature out of the container, the way the web app does.