摘要: 做java企业级开发时，我们通常采用三层架构。特别地，如果我们要做的系统的业务逻辑不是很复杂时，我们要处理的不过是CRUD操作，这时我们可能将dao层与service层合并为一层，尽管很多人会这样做，但我仍倾向于将两层分开；因为service与dao不是一一对应的，从复用及逻辑清晰的角度考虑，应该将它们分开。在三层架构下，对于web层，service层，dao层我们都该怎么测试？这里我将介绍基于Spring，Hibernate和DbUnit的情况下我的测试方法。由于使用了Spring，事务管理就不在dao，因此要单独地测试dao可能要麻烦一些；另一方面，dao中的操作大多是简单的，也不是很值得测试。在使用了Hibernate和Spring的情况下，我们要测试的除了HQL，还有其配置文件，我觉得对数据持久化的测试最好定在service上。如果service业务逻辑复杂的话，与数据持久化无关的业务逻辑（应该写在领域对象中）可以单独测试，在保证与数据持久化无关的业务逻辑的正确性下，带上dao操作做集成（单元）测试。  阅读全文

     摘要: 在做Java企业程序的时候，不可避免地要和外部资源打交道，比如数据库，Http请求等。对于这些外部资源的处理，我们可采取的操作或者是直接处理或者是模拟处理。当我们使用Webwork，Spring，Hibernate等框架时，我们要测试的并不仅仅是Java代码，我们还要测试依赖于这些框架的配置文件等等。因此，对于数据持久化的测试，Mock方法是行不通的，我们需要真实地测试数据库操作。对于持久化测试来说，重要的是创造出已知的“干净的”的准备数据。如果我们在测试一个持久化方法前不能确定数据库到底存着什么数据，我们只能通过反复地查看数据库数据来验证测试方法的正确性了（这就是我和大多数人以前使用的最“直接”的方法）。现在就让我们使用DbUnit，来更好的更自动化的测试持久化操作吧！

先介绍一下DbUnit。DbUnit是一个 JUnit扩展，适用于数据驱动的程序。使用DbUnit，可以在测试运行期间将数据库的数据处于已知状态，这样在测试时可以方便地写出测试断言，也能自动地完成对数据持久化方法的测试。在使用上，DbUnit也很简单， 它提供了大量的  阅读全文

     摘要: 我们应该如何以及在哪里使用Mock对象呢？一般来说，对于目标对象中的合作者对象，在测试时如果其状态或行为的实现严重地依赖外部资源（比如数据持久化中的DAO，比如负责发送电子邮件的类），或者团队并行开发时，目标对象的合作者对象并没有实现（比如J2EE中，横向分工时，负责Action的调用Service，负责Service调用DAO时，相应的Service及DAO没有实现），这时我们就需要模仿这些类。其实，在做J2EE时，传统的N层架构中，我们都是面向接口编程的，我们定义了DAO接口，我们定义了Service接口，这样做的优点就是我们在测试时可以构造实现接口的Mock类。这里不得不提依赖注入，通过依赖注入，我们才能在测试时set Mock对象。这也说明，为了方便测试，我们不得不一步一步重构代码，而模式就在重构中自然地产生了。
  阅读全文