JUnit实战一

[size=medium][b]1.单元测试：检测一个独立的工作单元的行为。
2.单元测试的必要性：带来更高的测试覆盖率；提高团队效率；监测衰退和减少测试；能为我们带来重构的信心，以及在一般情况下做出改变的信心；改进实现；将期望的行为文档化；启用代码覆盖率以及其他目标
3.测试类型：单元测试-->集成测试-->功能测试-->压力负荷测试-->验收测试
检测不同组件（可能此时它们正运行在目标环境中）之间的相互影响，这其实就是进行集成测试。
功能检测检查公共API边界处的代码，通常情况下，这相当于测试应用程序的用例。
压力测试用来检测应用程序是否能在某个特定的时间段内响应大量的用户请求。（JMeter）
验收测试是最终级别的测试，通常由客户或客户代理人进行验收测试，以确保应用程序已经满足了客户或者利益相关者提出的任何目标。验收测试是所有测试的超集，可能包括功能和性能，易用性，外观与感觉等。
4.单元测试类型：逻辑单元测试；集成单元测试；功能单元测试；
逻辑单元测试：这种单元测试主要针对一个单独的方法来检查代码。可以通过mock objects或者stub来空着某个特定的测试放的边界；
集成单元测试：这种单元测试主要用来测试在真是环境中（或者真实环境中的一部分）中不同组件之间的相互作用。eg，测试一段访问某个数据库代码时候真正有效的调用了数据库；
功能单元测试：这种单元测试已经超出了集成单元测试的边界，目的是为了确认一个刺激响应。
5.黑盒测试：不知道系统内部状态与行为。测试仅仅依赖与系统外部接口来验证他的正确性。（Selenium和HtmlUnit）
白盒测试：使用实现的具体知识来创建测试并驱动测试进程。
比较：黑盒测试的编写和运行都会比较困难；
白盒测试提供了更好的测试覆盖率；
黑盒测试比白盒测试能带来更多的价值。
6.测试覆盖率：（Cobertura）
指标之一是跟踪测试调用了哪些方法。这个指标无法告诉你测试是否完整，但是它可以告诉你，针对某个方法你是否有相应的测试。
7.编写可以测试的代码：
公共API 是协议：提供向后兼容性的软件状态的原则之一就是：永远不要改变一个公共方法的签名。必须测试所有的公共方法，而对于那些非公共的方法，则需要更深入一步，使用白盒测试。
减少依赖关系：一个解决方法是将代码隔离在两个类方法之间，一类是实例化new对象的方法，另一类是为应用程序提供逻辑方法。
创建简单的构造函数：为了尽量获得更好的覆盖测试率，我们增加了越来越多的策划死用例。而在每一个测试用例中，我们都要做到一下几点：一，实例化类，以便进行测试；二，将类设置到某个特定状态；三，断言类的最终状态。。通过在构造函数内部进行处理（除了填充实例变量之外），我们往往将以上的第一点和第二点混合在一起实现。事实上，无论是从架构的角度（每次实例化类的时候都要做同样的事情），还是因为我们总是使类处于某种预定义的状态中，这都是一种糟糕的做法。这样的代码是难以维护和测试的。
遵循最少知识原则：又称迪米特法则。一个类只要知道它需要的那么多即可。关键概念：要求对象，但不搜索对象，而且仅要求应用程序所需要的对象。
避免隐藏的依赖关系和全局状态。
单态模式的优点和缺点：确保对象只被实例化一次。但是在应用程序中引入了全局状态。
组合优先于继承：组合可能更容易测试。
多态优先于条件语句:如果类十分复杂的花，要实例化它就会比较困难。降低复杂度的方法之一就是，尽量避免使用的长的switch和if语句。
8.测试驱动开发TDD：测试驱动开发是一项编程实践，它要求开发者只有在测试失败的情况下才编写新的代码，并且消除重复。TDD的目标是“能正常工作的干净代码”。
优先编写测试会带来以下：设计代码的方法；关于代码如何工作的文档；对于代码的单元测试
TDD的流程：测试，编码，重构，（重复），提交
TDD的核心原则：一，在编写新代码前编写一个失败的自动测试；二，消除重复。
9.单元测试框架应该遵循的最佳实践原则：
每个单元测试都必须独立于其他所有的单元测试而运行；
框架应该以单个测试为单位来检测和报告错误；
应该易于定义要运行哪些单元测试。
10.领域对象：要测试的对象。
测试对象：用来与被测试对象交互的对象。[/b][/size]