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:丑陋的测试代码,不好测试的代码,预示,警示,提示。:)】"
没有评论:
发表评论