代码的行为与我的期望一致吗？
最根本的是，我们需要回答一个问题：“这段代码达到我的目的了吗？”先别太关心需求，当前要做的事情是确保一段代码的行为与期望一致。
代码的行为一直和我的期望一致吗？
工程师在设计桥梁的时候，必须考虑负载、强风、地震、洪水等等，不能在因洪水出现问题后说，“如果风和日丽就不会有问题了”。
程序开发亦是如此。记得以前开发的时候，一个模块开发完毕后，我就把那些相关的页面打开，按正常的顺序输入正确的数据把功能走一遍，如果都通过了就交给测试人员。而测试人员最喜欢的一件事就是找出开发人员的bug，他们会想法按错误的顺序输入错误的数据，然后等着bug出现。
结果是，我的程序出了一堆bug，它们大多数都是因为错误的顺序或者错误的数据，我气愤地跟他们说，“你如果按正常的顺序输入正确的数据就不会有问题了！”
但事实是，测试桥梁时，不能仅选择在风和日丽的一天，仅让一辆车顺利通过，这远远不够。同样的，在测试代码的行为是否与期望一致时，需要确认：在任何情况下，这段代码是否都与期望一致：比如文件不存在、权限不足、索引越界、网络断掉的时候。
我可以依赖单元测试吗？
不能依赖的代码是没有多大用处的。更为糟糕的是，那些我们认为值得信赖的代码（但其实是有bug的）有时候会让我们花费更多的时间去跟踪和调试。
没有人能够写出完美无缺的代码，但是这没问题——只要我们知道问题的所在就可以了。
我们希望能够依赖于所编写的代码，并且清楚地知道这些代码的功能和约束。
单元测试能否表达我的意图？
编写单元测试，一个额外的好处就是它能够帮助我们表达代码的意图。在效果上，它就像是可执行的文档，说明了在用各种条件调用代码时，我们对代码行为的期望。
当团队的其他成员看到测试代码后可以将其作为代码用法的示例。如果他发现了一个遗漏的测试用例，他会很快知道：代码可能不支持这个用例。
1.4 如何进行单元测试？
单元测试是较为简单易学的技术，如果遵循一些指导性原则，学习会变得更为容易和有效。
首先要考虑的是在编写测试方法之前，如何测试那些可疑的方法。有了大概一个想法之后，可以在编写实现代码的时候，或者在此之前，编写测试代码。
下一步，要运行测试本身，或者所在模块的其他测试，甚至是整个系统的测试，前提是它们要运行得相当快。重要的是所有测试用例都要通过，而不是仅仅新加的那个。这种基本的回归测试（Regression Test）可帮助我们避免对其他的测试带来间接的破坏。
我们还要借助于单元测试框架来进行测试，这样可以大大提高效率。相关的知识可在后面的文章中介绍。
1.5 可是我还是不想测试
看了上面的这些介绍后，也许你能理解单元测试的必要性，也许你还在犹豫，而且还有不少的理由。
文章来源于领测软件测试网 https://www.ltesting.net/
