P55
"一个已知方法的前置条件(preconditions):系统处于什么状态该方法可以运行。... 我们需要确认，当前条件不能满足的时候，程序的行为仍然是正确的。
在方法的最后，后条件(postconditions):你的方法将会保证哪些状态发生。程序返回的结果显然是要检查的，但如果程序有任何副作用，也需要检查。
[go] P55 <
[popexizhi:此处的preconditions 和 postconditions 让人想到testcase 的前后置条件，不知这个testcase 是否也可以当成自包含边界测试了:) ]"
P54
"5.3区间性
在一个好的面向对象的设计中，你通常不会使用一个原生类型（eg:int）来存储一个具有边界的值，如年龄，罗盘指针的角度等。
[popexizhi:这里的例子给出了如何解决私有变量的方法，写一个叫做checkInvariant()的方法，在类中对私有变量test。测试此部分时直接调用此方法，从而避免直接访问私有变量，而又确保内容本身没有越界。这里还回答了手工测试时的一个疑惑很久的问题边界测试是否需要，要多少的深度，这样看来，从测试本身来讲，只要考虑到的测试本身都不为过，只是针对不同业务和不同的开发时间而设置不同的轻重缓急而已。]
几乎所有的索引概念（不论是否为整型索引）都应该被大量的测试，以下一些建议供测试时使用:
开始索引和结束索引有相同的值
第一个索引大于最后一个索引
索引值是负的
索引大于允许值
Count不能匹配确切的索引个数"
P32
"用python的unittest测试的
setUp（）和 tearDown ( ) 是在每个testxxx()前后分别执行的；但是OneTimeSetup() 和 OneTimeTearDown() 在py2.6中的对应内容没有找到，
setUpClass() 和tearDownClass()作为@classmethod定义使用但在py 2.7，这个没有对应环境没有测试；
setUpModule(),tearDownModule()也没有效果，这个mark一下，以后研究[?]"
P119
"在一个设计良好的系统中，你首先就应该建立那些负责验证工作的系统部件，并且把这些部件都布局到一个小的，外界知道的系统部分中。
因此对一个系统，你需要提问的第一个问题就是:谁负责检查输入数据的有效性？通常，我们发现最简单的办法就是""别让野蛮人进门""在系统入口的位置就检查输入。
P120 那么这些和单元测试有什么关系？
它能告诉你哪些需要进行测试的。如前面说过，对于输入的数据，如果你的代码并不负责对它们进行检查，那么就不必在检查它们上面浪费时间。而如果是你的责任，那么就需要加倍地警惕--因为现在系统中的其余部分完成依赖于你的检查结果，并且只依赖于你的检查结果。"
P117
"如果你总在编写实现代码之前，就先编写它们的测试代码，那么你就是在使用测试驱动开发技术。这种编码方式的一个优势是你可以享受到“测试驱动的设计”的好处，并且大大改善接口的设计。
因为总是自己亲自调用这些接口，所以通常都能获得更好的接口设计。正如一句谚语所说:""你总是可以利用这些反馈来改善接口的设计""
也就是说，通过先编写测试，你把自己当做代码的用户，而非实现者。从这个角度，你能在接口如何被使用方面获得更多感知，从而有更多机会改善设计。
【popexizhi:TDD的好处是自己作为用户，通过反馈改善接口啊！：）嘻嘻刚刚知道】"
P116
"结构化
P115 最普遍的不变性是结构化属性，也就是说，这里的不变性指的是数据的结构化属性。
P116 不变性检查能够让你确信另一个事实:你并不是基于某种巧合，才令测试通过的.这是因为，对于一个实际存在的bug，即使显式的测试并没有捕捉到它，不变性或许也可以帮你提前捕捉到这个bug。
【popexizhi:不变性检查的另一个好处是让抛出异常位置为错误的位置相关，这个原文是用例子说明的，这里没有写，标记一下】"
P103
"我要如何对代码进行测试呢？
如果答案并不显而易见，或者测试代码看起来写得非常丑陋，甚至难以编写的话，那么你应该把这种情况看成一种征兆。它暗示你的设计可能需要修改，改变一些设计，直到让代码易于测试为止，最后通过这些努力，你的设计一定会好很多。
【popexizhi:丑陋的测试代码,不好测试的代码，预示，警示，提示。:)】"
没有评论:
发表评论