Jon*_*eet 19
关于什么构成什么样的测试,不同的人有不同的想法,但这里有一些关于我认为每个术语的含义的想法.请注意,这严重偏向服务器端编码,因为这是我倾向于做的:)
单元测试
单元测试应该只测试一个逻辑代码单元 - 通常是整个测试用例的一个类,以及每个测试中的少量方法.单元测试(理想情况下)小而且便宜.与依赖项的交互通常与测试双重隔离,例如mock,fake或stub.
整合测试
集成测试将测试不同组件如何协同工作.外部服务(不属于项目范围的部分)可能仍然被伪造以提供更多控制,但项目本身内的所有组件都应该是真实的.集成测试可以测试整个系统或某个子集.
系统测试
系统测试就像集成测试,但也有真正的外部服务.如果这是自动化的,通常将系统设置为已知状态,然后测试客户端独立运行,发出类似真实客户端的请求(或其他),并观察效果.外部服务可以是生产服务,也可以是仅在测试环境中设置的服务.
探测测试
这就像一个系统测试,但使用生产服务的一切.它们会定期运行以跟踪系统的运行状况.
验收测试
这可能是最不明确的术语 - 至少在我看来; 它可以有很大的不同.它通常是相当高的级别,如系统测试或集成测试.验收测试可以由外部实体(标准规范或客户)指定.
黑匣子还是白盒子？
测试也可以是"黑盒子"测试,它只接触公共API,或"白盒子"测试,利用一些额外的知识来使测试更容易.例如,在白盒测试中,您可能知道所有公共API方法都使用了特定的内部方法,但更容易测试.您可以通过直接调用该方法来测试许多极端情况,然后使用公共API执行更少的测试.当然,如果你正在设计公共API,你可能应该将它设计为易于测试 - 但它并不总是那样.通常能够独立地测试一个小方面是很好的.
另一方面,黑盒测试通常不如白盒测试脆弱:根据定义,如果您只测试API在其合同中保证的内容,那么实现可以根据需要进行更改,而不会更改测试.另一方面,白盒测试对实现更改很敏感:如果内部方法发生微妙变化 - 或者例如获得额外参数 - 那么您将需要更改测试以反映这一点.
这一切归结为平衡,最终 - 测试水平越高,黑盒子的可能性越大.另一方面,单元测试可能包括白盒测试的元素......至少在我的经验中.有很多人谁也不肯在所有使用白盒测试,只有不断测试公共API.对我来说,这感觉更加教条而不是务实,但我也能看到它的好处.
开始
现在,至于你应该去哪里 - 单元测试可能是最好的开始.您可以选择在设计课程之前编写测试(测试驱动开发),或者在大致相同的时间,甚至几个月后编写测试(不理想,但是有很多代码没有测试但是应该) .你会发现你的一些代码比其他代码更容易进行测试...... 使测试可行的两个关键概念(IMO)是依赖注入(编码到接口并为你的类提供依赖,而不是让它们实例化那些依赖项)他们自己)和测试双打(例如,模拟框架,让你测试交互,或虚假的实现,在内存中做一切简单的方式).