你还可以使用前面我们说到的另两个命令，使测试反馈以图形化的形式体现出来，例如，执行java junit.awtui.TestRunner testQueue， 将出现：
图1
第二次迭代
接下来，我们修改测试程序，加入测试案例TC04、TC05的考虑。
import junit.framework.*;
public class testQueue extends TestCase
{
protected Queue q1,q2;
public static void main (String[] args)
{
junit.textui.TestRunner.run (suite());
}
protected void setUp() {
q1= new Queue();
q2= new Queue();
q2.inqueue("first"); /对队列q2执行插入队列操作
q2.inqueue("second");
}
public static Test suite()
{
return new TestSuite(testQueue.class);
}
public void testEmpty()
{
assertTrue(q1.empty());
//当队列新建时，应为空-TC01
}
public void testInqueue()
{
assertTrue(!(q2.empty()));
//执行了插入队列操作，队列就应不为空-TC05
assertEquals(1,q2.search("second"));
//search方法用于确定元素在队列中的位置
//后插入的数据元素，应在未尾-TC04
//插入两个，第一个在位置0， 第二在位置1
}
}
根据这个测试代码，我们需要在Queue类中添加上inqueue（） 和search（） 两个方法，如下所示：
public class Queue extends java.util.Vector
{
public Queue()
{
super();
}
public boolean empty()
{
return super.isEmpty();
}
public synchronized void inqueue (Object x)
{
super.addElement(x);
}
public int search(Object x)
{
return super.indexOf(x);
}
}
编译之后，再次执行java junit.awtui.TestRunnertestQueue， 你将再次看到成功的绿色。
图2
我们仔细看一下这一界面。
1） 最上面列出了测试代码的类名，右边有一个"Run" 按钮，当你需要再次运行这一测试代码时，只需单击这个按钮。另外，将"Reload classesevery run" 选项打上勾很有用，当你测试未通过（出现红色时）， 你可以转身去修改代码，修改完后，只需再按"Run" 按钮就可以再次运行。
2） 中间区域是一个状态汇报区，红色表示未通过，统计了共运行了多少个测试（也就是在TestCase类中方法的数量）。
3） 如果测试时出现错误，例如，我们不小心将"assertTrue(!(q2.empty()));" 误写成为"assertTrue(q2.empty());" 就将造成测试失败：
注:由于第一个测试还是通过的，因此你会看到绿色条一闪。这时，你将会发现JUnit会将错误列出来，并且对应的"Run"按钮也由灰变成了亮，这表示你可以转身修改，完成后单击这个"Run按钮"可以只做刚才失效的这个测试，这将节省大量的时间。
同时，在最下面的窗体里，列出了失效的详细原因。
后面的迭代
到这里，开发还没有完成，但这种思想却已经通过这样两个短小的实践传递出去了，后面的活大家可以动手试一下。
另外值得一提的是，这里虽然洋洋洒洒一大篇，实际两次迭代花费了我不到15分钟就完成了。而且，当看到绿条时，心里十分舒畅。
一些遗憾
文章到此就告一段落，但却有些许遗憾。
遗憾之一:这只是一篇文章，没有办法把所有方面都讲得面面俱到，以致于大家可能无法马上上手。
正是由于这样的原因，本文取名为"感悟"， 与大家交流一下体会，希望能够帮助大家更好地接受"测试驱动开发"的理念，并开始着手实践。
遗憾之二:笔者水平有限，无法解决大家的各种问题。
让笔者感到欣慰的是，记载着这些答案的《测试驱动开发》、《敏捷软件开发》、《拥抱变化： 解析极限编程》等大作都已悉数摆上了中国的书店。路虽难走，但明师已有。
实践永远是学习的最好方法，看到笔者的感悟，就开始极限之旅吧，因为那里风光无限，乐趣无限。当你掌握了测试驱动开发的精髓，那你就能够对你自己编写的所有代码充满信心，不再担心它们什么时候在你的后面放一冷箭，从此告别这给你带来无限压力的苦恼。
