所以说，TEST FIRST是提高测试代码正确性的一个很好的途径。这里先写开发代码后写测试代码的方式，其实说白了，是我想说的第三点，那样的测试，真的就很容易成了为了测试而测试的代码（记忆里，以前我这么做的时候，还都是为了测试而测试，呵呵，不知道其他朋友会如何）。
二、只写出需求测试（注意，是目标代码需求，这个代码的用户当然是自己了，^_^）
前面说到，要保证测试代码的正确性，从保证代码本身的清晰来入手，只写需求测试也是一个道理，不过要把它放在这里，主要也还是因为自己以前写测试的时候，往往都很容易忘记这一点，简单的比方说，当一个测试会牵涉多个类的时候，本来其实也很明确的，单元测试嘛，你测试你的目标类就OK了呗，但是每个人的认识不同，写测试的水平不同，更在于小心谨慎，总是在写目标类测试的时候，想这个地方虽然是A类做的事情，不过我也连带着加个断言看下A做对了没有吧，反正也就多加一句，以防万一嘛（太小心了，其实过界了都不知道）。别小看一行代码，我的感觉，超过20行（空行不算，sweat）的一个方法在你写完这个方法几个月后回来看，晕的几率很大，至少要立刻明白这个方法的内部结构是基本不能。积少成多，如果目标类关联了A、B、C、D、E五个甚至更多，多出来的恐怕就不是一、二行代码了，而且你一次小心一定会多次小心的，比如，在一个测试用例中（我所指的测试用例不是指TESTCASE类，而是该类中的一个TEST方法）你的断言中包含了对A的一个操作结果的测试，那么在另一个测试用例中，如果还用到A的这个操作，我肯定你还会写这个断言，因为你第一次的小心不是偶然。人说，小心使得万年船，不过，杞人忧天就过犹不及了。而写测试的时候，是很容易就会犯这样的错（唉，其实是我当初很容易犯这样的错，sweat）。
所以，职责分明，只写你需要的你该做的测试，别一开始就怀疑这个怀疑那个，处处小心，步步为营。我们要如何使用我们的代码，那么就写那样的测试，现在我都是拿测试代码当例子，写了一个公共模块，除了有文档以外，都是建议要是觉得看文档麻烦就看测试代码如何使用，或者你干脆就拷贝我的测试代码过去改下用好了。
三、不要为了测试而测试（这句话是和一个朋友聊天时他说是他和Kent Back交流时Kent Back提醒他的，这里我也不是很确定对这句话的理解的正确与否，因为理解一句话，上下文也是关键的，而我并不很了解我朋友同Kent Back谈话的具体内容和过程，不过这里还是作为一个要点谈谈自己的想法）
不要为了测试而测试，^_^，虽然说要写测试，不过大家都是开发的，如果你的测试代码的目的成了测试，我还是会说你这就不够“专业”了。（这句有点耳熟，星星：拜托，虽然大家都是中国人，你要是抄我台词，照样要告你剽窃）
其实开始我听朋友讲这句，似懂非懂，因为毕竟只是一句没头没尾的话，听过就算了。但是细细品了，确觉得有些道理（^_^，不知道我的想法是不是Kent Back说这句话的本意）。言归正传，开发人员的测试代码，还是不要以测试目标代码为目标的好，这样才能更好的确保测试代码的正确性。
这里要澄清的是，不是说测试代码就不要去拿来测试了，呵呵，测试代码的结果（无论是否测试先行）其实都是一样的，都是可以自动（或者半自动，^_^）执行的测试，我说了，是写测试的目的，由于你的目的不同，中间的过程也是大不相同的，对于开发人员来说，开发代码是最终目的（什么需求分析、系统设计啦等等等等，还不是为了能满足用户需求的代码出来给用户跑嘛，哦，当然，最最终目的，咱还是靠这个养家糊口，sweat），所以开发过程中的单元测试代码，它只是辅助我们开发的（这点好像说了好多遍了，sweat，别丢我臭鸡蛋），所以这些测试代码的最终目的也是为了开发代码，它和测试人员写的测试代码有本质的区别（测试人员要是来看我这篇文章，嘿嘿，SORRY啦，真不是为测试写的）。
说得好绕口，不过，只有清楚了这点，那么前面2点才会站得住脚，如果一开始得测试代码就只是为了测试目标代码得功能，那么TEST FIRST就是笑话了，连目标都没有怎么可能测试，而根据需求写测试，根本不管内部逻辑以及边界条件等等等等什么这覆盖那覆盖的测试，测试人员一定说我瞎掰了，这也能拿来测试？
所以，要保证测试代码的正确性，别为了测试而测试，只有不为了测试而测试，你才会真正做到第一、二点。（好像这点应该摆第一去，sweat，不过既来之则安之落）
四、每次写一点（原子级）测试
这一点，其实说白了，是XP中的小增量迭代，测试驱动开发强调虽然是测试优先，但是测试开发并行过程中相互的交互作用是很关键的。
一个很笼统的测试用例，既测试这个又测试那个，难免会复杂起来（量的积累带来质的变化），所以最好是一个测试用例只针对一个需求写测试，少量多次嘛。添加一点测试，运行失败，修改代码，运行测试，直到成功，然后重构代码，最后测试通过，是测试驱动开发的一个小迭代周期，当然迭代周期的控制是可以因人而异的。
每次写的测试越少，那么表示你关注的问题或者需求就越少，那么精力就越集中，相对的测试的代码量也越少，大问题通常都可以通过将其拆分成多个小问题分别解决来得到解决，如果觉得测试代码太复杂，自然也可以通过拆分复杂的测试代码为多个小的相对简单的测试代码段来缩小其复杂性。
文章来源于领测软件测试网 https://www.ltesting.net/
