下面终于该Mock Object 出场了，事实上，你的测试就是很好的Mock例子。在测试中，你验证了如果blogService.save(blog) 被调用，blogDao的save(blog) 一定也会被调用，而且被调用时，参数一定是 blog。也就是说，你验证了blogDao必须以这种特定的形式参与测试。
通过比较，我们可以看到，从Dummy Objec到 Mock Object，测试代码对TestDouble 的要求越来越强，验证的内容也越来越强。这种强制约有好处也有坏处，不过，总的来说，我们希望够用就行。换句话来说，如果能验证代码的正确性，如果Stub够用，就不要用Mock，因为Stub比Mock简单，Stub 对被测代码的制约也小的多，所以被测代码改起来也更容易。
为什么有些时候必须用Mock呢？一个常见的情况是需要参与的方法没有返回值。例如blogDAO.save(blog)。首先，我想说的是，这行代码非常重要，是一定要测试到的。不然的话，你把这行从BlogService中删掉，都没有测试报错，这显然不对。问题是blogDAO.save(blog) 没有返回值，我们怎么才能知道它被正确调用了呢。当然，我们可以用TestSpy，象上面的例子。不过，一般的Dynamic Mock framework 都不支持象上面那类的TestSpy，所以你要手写TestSpy。如果你不愿手写，我认为用Mock是完全可以接受的。这里我还想说的是，它没有“深入到DAO的接口设计中去了”， 因为你的测试只是验证blogDao的save(blog) 会被调用，而没有验证save(blog)的结果是不是正确。如果你验证save(blog)的结果是不是正确，那才是“深入到DAO的接口设计中去了”。所以总的来说，我认为你用Mock 测试是perfectl valid。一点小毛病是，在测试中，你没必要去setTitle("title")， setContent("content")，setCreatedTime(new Date())，这些跟你要测的东西没有任何关系。
一些comments：
“测试代码本来只需要知道传什么参数给Service，并且预期测试Service返回什么值就够了，管它DAO调用什么方法干嘛？”
--理想情况下是，问题是， Service没有返回值，更讨厌的是，连DAO都没有返回值，我们有不能让它沉到太平洋里去，那怎么测试，只好用没办法的办法，验证blogDao的save(blog)将 被调用。
“整个Service的实现对测试代码应该是不可见的“
--理想情况下是，现实中常常不是，尤其是Service class 自己没什么逻辑，but just some interaction with other classes. 例如，Service class 接受一个DTO参数， 然后，用Mapper 把它Map 成Entity object，用Validator 去 validate， 用 logger 写 一个 log， 最后用DAO 存到数据库。这种情况下，你不得不做一些基于Mock 的Interactive 测试。
最后，我的观点，
·尽量少用 Mock
·该用Mock的时候就用，Mock没什么可怕的
·明白测试的目的是最重要的
