《单元测试之道Java版》的笔记 note(三)

P81 它能在你下坠时及时抓住你，但是它们不会挡住你前进的道路。因此，当自动化被破坏的时候，就需要你百分之百的注意力。


[popexizhi: unittest 的优秀之处，一句“它能在你下坠时及时抓住你，但是它们不会挡住你前进的道路。” 概括明了，良好的unittest是一张安全网，防坠用的：）]


P83 每个测试应该独立于其他的测试，而且还必须独立于周围的环境，目标应该只有一个，就是测试应该能够以任意的顺序一一运行，并且产生相同的结果。这意味着测试不能依赖于不受你直接控制的任何外部因素。


[popexizhi: 这里虽然是对unittest的要求，但是在功能测试用例运行时存在相同的问题，测试用例的前置测试用例是否对测试的系统运行要求过高了？这个主题下，确实在测试用例的执行时设置太多的前置测试用例不太合适。可以要求前置功能但不能要求前置测试用例有数据依赖。这里的目标是将测试本身独立和分散开，不相互依赖，可以随时取用，可以再好好思考一下这样的好处和问题：）]


P84-85 调入编写非常冗余的测试代码的陷阱是非常容易的;也就是说，代码总是一遍又一遍的做相同的事情，其中甚至连一个对象或函数都没有，这是糟糕的事情。测试代码必须以同产品代码相同的代码的风格来编写。这意味着需要抽取出共同且重要的代码，并把它们的功能放入一个函数之中，从而可以多出调用此函数。


你可能发现你累积了几个相关的测试方法，此时应该把他们封装在一个类中。此时没有必要再犹豫，大胆地去创建一个新类来实现封装，即使它只用于测试。这种方法不仅仅是可行的，还应该得到鼓励；测试代码是真实的代码。在一些情况下，你甚至需要创建一个更大的框架，或者创建一个数据驱动的测试设施。


[popexizhi:最初还是编写unittest时,自己就调入了冗余代码的问题中，通篇的相同个格式的调用，主要是数据驱动部分，这个很验证，这里看来这个改进不仅是可以的，而且是必须的，好好思考一下这个结构如果去做了：）。至于封装为类等就是下一步事件的，这个对其他位置的unittest复用猜想应该有帮助吧！]


P85 意料中的结果是编写的测试代码至少应该和产品代码一样多。是的，你没有看错，那是对的。。。。。。测试代码确实很多，这也是为什么需要它保持简洁且精炼，设计良好且重构充分，如产品代码一样专业的部分原因