先编写测试
练习先编写失败的测试,在实现任何生产代码之前定义所需行为。
先编写测试 是 CoddyKit 上的免费 Testing Mastery: JUnit, Mockito & Integration Tests 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Testing Mastery: JUnit, Mockito & Integration Tests 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Testing Mastery: JUnit, Mockito & Integration Tests 课程共包含 4 节课。
本课时的部分内容尚未翻译,以英文显示。
TDD's 'Red' Phase
Welcome to the core of Test-Driven Development (TDD)! In this lesson, we'll dive into the crucial first step: writing a failing test first.
This is often called the 'Red' phase of the TDD cycle, because when you run your tests, you expect to see a 'red bar' indicating a failure.
Why Test First?
It might feel counter-intuitive to write a test for code that doesn't exist yet, or isn't fully implemented. But this approach offers great benefits:
- Clarity: It forces you to think about what the code should *do* before you think about *how* to do it.
- Proof of Failure: It proves your test works correctly by showing it can fail. If it passes without any code, your test might be faulty!
- Focus: It gives you a clear, immediate goal: make this one test pass.
Tests as Specifications
Think of your failing test as a precise specification or a mini-requirement. It describes a specific behavior your future code must exhibit.
- It defines the input.
- It defines the expected output or outcome.
- It's concrete and executable.
This helps prevent misunderstandings and ensures your code delivers exactly what's needed for that specific scenario.
Scenario: Simple Calculator
Let's practice by building a simple Calculator class. For our first piece of functionality, we want it to be able to add two numbers.
Our goal is to write a test for an add method that will fail before we even write the correct implementation of add.
Designing the Failing Test
Before writing code, let's think:
- What input? We'll add
2and3. - What output? We expect the result to be
5. - What method? A method called
addon aCalculatorobject.
We'll write a test that calls calculator.add(2, 3) and asserts that the result is 5.
Code Demo: The Failing Test
Here's a simulated example of writing a test first. Notice the Calculator's add method is intentionally incorrect (it returns 0). This makes our 'test' fail, demonstrating the 'Red' phase.
Run this code to see the simulated failure!
public class Main {
public static void main(String[] args) {
System.out.println("Running a simulated test...");
Calculator calculator = new Calculator();
// Our test scenario: 2 + 3 should be 5
int expected = 5;
int actual = calculator.add(2, 3);
if (expected == actual) {
System.out.println("Test PASSED: 2 + 3 = " + actual);
} else {
System.out.println("Test FAILED: Expected " + expected + " but got " + actual);
System.out.println("This is our 'Red' phase!");
}
}
}
// The production code (intentionally incorrect for 'Red' phase)
class Calculator {
public int add(int a, int b) {
return 0; // Wrong implementation to make the test fail
}
}Analyzing the 'Red'
After running the previous code, you saw a 'Test FAILED' message. This is exactly what we wanted!
- Expected:
5 - Actual:
0
This failure confirms two things: our test is correctly written, and the production code (the add method) does not yet meet the specified behavior.
The 'Minimum Code' Mindset
Once you have a failing test, the next step in TDD (the 'Green' phase) is to write the *simplest possible code* to make that test pass.
- Don't over-engineer.
- Don't add extra features.
- Just focus on satisfying the current failing test.
This keeps your code clean and focused, building functionality incrementally.
Advantages of Test-First
Embracing the 'Red' phase of TDD leads to:
- Better Design: Tests guide you towards more modular and testable code.
- Increased Confidence: Each passing test gives you confidence in your code's correctness.
- Reduced Bugs: Catch issues early, before they become complex problems.
- Living Documentation: Your tests serve as up-to-date examples of how your code should be used.
Quick Check on TDD Red
Let's test your understanding of the 'Red' phase in Test-Driven Development.
Recap: The 'Red' Phase
You've explored the crucial first step of TDD: writing a failing test.
- The 'Red' phase means writing a test that fails.
- This test acts as a clear specification for new functionality.
- Seeing the test fail confirms its validity and that the code isn't yet correct.
- This methodical approach leads to clearer requirements and more robust code.
Next, we'll learn how to make that failing test pass – the 'Green' phase!
常见问题解答
「先编写测试」课时是免费的吗?
是的 — 「先编写测试」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Testing Mastery: JUnit, Mockito & Integration Tests 课程的其余内容,请升级到 CoddyKit PRO。 Testing Mastery: JUnit, Mockito & Integration Tests 课程共包含 4 节课。
「先编写测试」这节课中我会学到什么?
练习先编写失败的测试,在实现任何生产代码之前定义所需行为。 你通过在浏览器中直接运行的动手代码来练习 Testing Mastery: JUnit, Mockito & Integration Tests,全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Testing Mastery: JUnit, Mockito & Integration Tests 需要有经验吗?
无需任何先前经验。CoddyKit 上的 Testing Mastery: JUnit, Mockito & Integration Tests 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 2 节课,共 4 节。
「先编写测试」课时需要多长时间?
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。
我能在这节 Testing Mastery: JUnit, Mockito & Integration Tests 课中编写并运行代码吗?
能。每节 Testing Mastery: JUnit, Mockito & Integration Tests 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。