单元测试是一种测试，所以，我们应该以一种测试的眼光去面对它——我们要测试正常情况，边界条件，要对它的测试目标——函数做黑盒分析，白盒分析，选择合适的测试数据，构建测试场景和测试环境——总之，一切测试应该做的事情，单元测试都不应该省略。
理论上来说，单元测试和其他测试一样，也是可以纯手工完成的：我们可以写一段某函数的测试代码，然后输入我们的测试输入，观察测试输出，并跟期望值做比较——事实上这种人工测试，写了一段时间代码的人应该都不会陌生。但是，单元测试有一点特殊性，就是在一个系统中，函数会非常非常的多，变化也比软件的功能频繁的多。面对这么多的函数，这么频繁的变化，纯手工测试是不现实的。所以，我们必须要引入单元测试框架进行自动化测试。注意，这里的单元测试框架只是实现自动化测试的一个手段，对单元测试本身并不产生任何影响——没有单元测试框架，单元测试一样也是可以进行的，只是会痛苦很多。
单元测试框架引入的目的只是为了自动化单元测试，简化单元测试的步骤。所以，对于测试代码的编写，我们的重点应该是：1、如何搭建测试环境、测试场景；2、如何选择测试用例；3、如何校验测试结果。对于测试代码本身，应该尽可能的简单，能不要使用技巧尽量不要使用，我们的目的在于测试，如果测试本身过于复杂，我们不能保证测试的正确性，测试这个工作就白做了。
另外，刚刚提到单元测试是对函数的测试，因此，测试必须是以函数为单位的。每个函数应该拥有自己单独的一个测试，但是在这个测试中，我们应该针对这个函数的各个方面：正常的、异常的、边界的……等等，各个方面进行完善的测试，这样我们才能保证这个函数的功能是如我们所愿的。但是单元测试不需要负责函数的组合工作情况。那应该是(低层次)功能测试的工作，而不是单元测试的工作。这个功能测试就是在假定所有函数都工作正常的基础之上，对这些函数组合形成的功能模块进行测试。这种测试，视情况而定，可以使用单元测试框架，也可以使用其他自动化测试方法或者甚至是使用纯人工测试。
另外，我还想讨论一下单元测试的编写和运行。
绝大部分时候，单元测试的编写，是由开发人员做的。我们在以前某次对单元测试的讨论中，甚至有人认为，单元测试必须由开发人员完成，而不应该由独立的测试人员完成。对于这个问题，我是这样看的：测试是一种针对需求的验证工作。如果这个需求非常清晰，清晰到开发人员之外的人都可以轻易掌握（有些日本外包发出来的函数说明书就能达到这一点），这时单元测试可以由独立的测试人员完成。但是大部分情况下对于函数级别，做不到这一点。这时最清楚函数需求的人就是开发人员本人，在这种情况下当然就应该是开发人员自己编写测试用例。但是开发人员必须搞清楚自己身兼两个不同的角色：运动员（实现代码）和裁判员（检验代码），在编写测试用例的时候绝不能假定任何函数的实现，而应该完全按照它应该有的需求来做。这样才能做好单元测试这件事。很多时候单元测试形同虚设，就是因为开发人员没有很好的转换自己的角色造成的。
单元测试的运行，目前我们这个Python的项目比较容易，直接运行模块就是该模块的单元测试，而以模块形式import就是实际使用。对于像C++或者其他的一些语言来说，可能没有这样方便的形式。我们可以把测试写在独立的文件中，然后用makefile组合不同的项目和主函数来做到这一点。另外还有一点就是，实际运行过程中可能会有一些环境，这些环境在测试时难以获得，或者增加上去之后，就难以测试（比如网络环境、数据库环境等等），这时我们可以采用一些虚拟的环境来做到。我们把运行时需要的环境做一个简化的虚拟版本，然后以这个版本作为测试环境进行测试，对于Python来说，我们可以实现这样的一个库在测试时import进来并且同时做一些环境初始化工作，在C++里，我们可以专门为测试写一些运行库，在实际运行编译和测试编译时，链接不同的库。这在自动化测试技术中有个专门的名称叫做 Mock Object。关于这个，我就不再深入了
文章来源于领测软件测试网 https://www.ltesting.net/
