Vibe Coding · 课时

通过提示词生成测试

让人工智能编写有意义的测试。

通过提示词生成测试 是 CoddyKit 上的免费 Vibe Coding 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Vibe Coding 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Vibe Coding 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Tests Are Your Safety Net

When AI writes most of your code, tests become the contract that keeps it honest. Each assertion is a promise the assistant cannot silently break.

The goal is not 100 percent coverage for its own sake. It is to pin the behaviors you care about so that future generations cannot regress them.

This lesson is about prompting your way to a test suite worth trusting.

Describe Behavior, Not Implementation

Weak prompts ask the model to "write tests for this function." The result mirrors the implementation and passes trivially, even when the code is wrong.

Strong prompts describe the expected behavior in your own words. The test then encodes intent, not the model's reading of the existing code.

Specify inputs, outputs, and invariants the way a product spec would.

Write tests for the checkout function based on these rules, not on the current implementation: total must equal sum of line items minus discount; discount can never exceed subtotal; an empty cart must throw. Cover the boundary at exactly zero and at the discount cap.

Start With the Failing Case

Tests that only confirm the happy path give false comfort. Ask for the cases most likely to break first: nulls, empties, limits, and malformed input.

A suite that exercises failure modes is the one that catches real regressions. The boring success case rarely surprises anyone.

Front-load the edges and you front-load the bugs.

Generate tests that focus on failure and boundary conditions for this parser: empty string, whitespace only, max length plus one, invalid unicode, and deeply nested input. For each, assert the exact error type and message the code should produce.

Beware Tests That Pin Bugs

If you ask a model to write tests against existing code, it may assert the current buggy behavior as if it were correct. The suite goes green while the bug stays.

This is the single biggest trap in AI test generation. The test documents the defect instead of catching it.

Always review whether each assertion reflects what you want, not merely what the code currently does.

For each test you generated, tell me explicitly whether the expected value is derived from my stated requirements or from observing the current code's output. Flag any assertion that simply mirrors existing behavior so I can verify it is actually correct.

The Arrange-Act-Assert Spine

Readable tests follow a clear shape: set up state, perform one action, assert one outcome. Models drift into multi-assertion mega-tests that are hard to debug when they fail.

Ask for focused tests with descriptive names that read like specifications.

A failing test should tell you exactly which behavior broke, in its name alone.

Refactor these tests so each one follows arrange-act-assert, tests a single behavior, and has a descriptive name that reads like a sentence describing the expected outcome. Split any test that contains unrelated assertions.

Mocking the Right Boundaries

AI often mocks too much, stubbing out the very logic under test until the test asserts nothing real. Or it mocks too little and hits a live database.

Mock at the system boundary: network, clock, filesystem, payment gateway. Keep your own business logic real.

State the boundary explicitly so the model does not guess.

Write these tests so that only external boundaries are mocked: the HTTP client, the system clock, and the payment provider. Do NOT mock our own pricing or validation logic; that logic must run for real so the test exercises it.

Property-Based Thinking

Example tests check specific inputs; property tests check invariants across many generated inputs. "Reversing a list twice returns the original" holds for every list.

Asking the model for property-based tests surfaces bugs that hand-picked examples miss, because the framework hunts for counterexamples.

Use them where invariants are clear: encoders, sorters, serializers, math.

Write property-based tests for the serializer using a generative testing library. Assert the round-trip invariant that decode(encode(x)) equals x for any valid input, and let the framework search for the smallest failing case.

Coverage Without Theater

Coverage percentage is a map, not the territory. You can hit every line while asserting nothing meaningful. Models love padding suites to chase a number.

Use coverage to find untested branches, then judge each by hand: is this path worth pinning?

Aim for tests that would fail if the behavior were wrong, not tests that merely execute the code.

Run coverage and list the uncovered branches in this module. For each one, tell me whether it represents a meaningful behavior worth testing or trivial code I can ignore, and propose a focused test only for the meaningful ones.

Mutation: Testing Your Tests

A green suite that survives any code change is worthless. Mutation testing introduces small bugs and checks whether your tests notice.

If a mutant survives, your tests do not actually constrain that behavior. The model can propose mutations and you verify your suite kills them.

This is how you measure test quality, not just quantity.

Propose five small mutations to this function, such as flipping a comparison or removing a guard, that would represent real bugs. For each mutation, tell me whether the current test suite would catch it, and write a new test for any mutation that survives.

Make Tests Deterministic

Flaky tests erode trust until people ignore failures entirely. The usual culprits are real time, random seeds, network calls, and test ordering.

Demand deterministic tests: inject the clock, fix the seed, isolate state between runs. A suite you cannot trust is worse than no suite.

Reliability is a feature of the tests themselves.

Make this test suite fully deterministic: inject a fixed clock instead of reading current time, seed all randomness, remove any reliance on test execution order, and ensure each test resets shared state in setup and teardown.

Tests As Living Spec

A good suite doubles as documentation. New contributors, human or AI, learn the system's rules by reading the assertions.

Keep test names and structure clear enough that the suite explains intended behavior on its own. The model reads them too, and writes better code as a result.

Your tests become the durable memory the model lacks.

Quick Check

Test your grasp of prompt-driven test generation.

Recap

Prompt tests from behavior and requirements, not from the implementation, so they catch bugs instead of pinning them. Front-load failure and boundary cases, mock only at boundaries, and use property and mutation testing to measure real strength.

Keep the suite deterministic and readable so it serves as a living spec. Next, you will hunt for security gaps the model left behind.

常见问题解答

「通过提示词生成测试」课时是免费的吗？

是的 — 「通过提示词生成测试」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Vibe Coding 课程的其余内容，请升级到 CoddyKit PRO。 Vibe Coding 课程共包含 4 节课。

「通过提示词生成测试」这节课中我会学到什么？

让人工智能编写有意义的测试。你通过在浏览器中直接运行的动手代码来练习 Vibe Coding，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Vibe Coding 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Vibe Coding 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「通过提示词生成测试」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Vibe Coding 课中编写并运行代码吗？

能。每节 Vibe Coding 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Vibe Coding