Issue 1: Poor integration tests, as everything is being tested in isolation

I’ve had good experience with mock-based testing. However, it’s obvious that mocks will only test classes in isolation. I use both unit tests and integration tests (sometimes called system or acceptance tests) together. The need for integration tests is not an issue for mock-based techniques and is not a good reason to use less mocks. It’s just a different aspect of testing. A more common issue in my experience is that people in the agile community who are new to testing often don’t understand these different aspects of testing and seem to believe that mock-based unit testing and integration testing are mutually exclusive options. The lack of common terminology in the community only worsens the problem. For some people, a “unit” is a class or small group of tightly coupled classes. For others, it’s a large portion of the software product. Most agile developers seem to call every test they write a unit test. It’s become so confusing for some teams that I’ve seen terminology like “integration unit tests” being used to describe testing strategies.

But, back to the topic. Poor integration testing is simply the result of lack of integration tests. Mocks do not cause a lack of integration tests. A team makes that choice, probably based on a weak understanding of the tradeoffs between isolation (unit) and integration (system) testing.

Issue 2: Mocks add complexity to the software design.

“I’ve seen numerous occasions where the introduction of mocks has added a large amount of complexity to an otherwise simple design. This complexity leads to higher implementation costs, a higher cognitive load on the developers working on the system, and higher maintenance costs (as there’s more code to maintain). “

The author appears to focused on the increased use of interfaces when using mock-based testing and expresses the opinion that interfaces should only be used where we’d want to be able to replace one implementation with another. First, there are other reasons to use interfaces. In general, interfaces are useful for managing dependencies between software components or subsystems. This can be beneficial even if the implementations do not change (see The Dependency Inversion Principle).

A modular software design will generally make it easier to use mock-based testing without altering the design specifically for the mocks. However, there are times when the software must be modified to support testing. Fortunately, the changes needed to support testing often, if done well, support the modularity goal.

In my experience, extra interfaces don’t add a significant maintenance overhead. Most effort is spent implementing the interface. The time writing the interface itself (or extracting it using an IDE’s refactoring tools) is negligible.

My Conclusions

In almost every case, I see the “simplicity” gained by not using mocks overshadowed by complex test setups to initialize large groups of dependent objects. The dark side of integration testing is that it’s often very slow for large numbers of tests. Some teams are using continuous integration tools like Cruise Control to run their “unit tests” (usually they are actually integration tests). This delays the feedback about broken builds but is often necessary because the tests run so slow. I realize there other reasons for using CC, but this is a common one from what I’ve seen and heard.

I’ve worked on teams where we had thousands of tests that ran in less than 15-20 seconds total on a developer workstation. This was a direct result of heavy use of mock-based testing. We also had a slower suite of integration tests that required 4-5 minutes to run. We didn’t need a continuous integration server because we were able to integrate and run our unit tests before every commit to the source control system. The team integrated 10-20 times/day and broken builds were practically nonexistent over the several years I worked with them. In the very rare cases when the build did break, it was typically fixed in a matter of minutes.

The other benefit of the isolation testing enabled by mocks is the ability to pinpoint problems much more quickly. It’s a form of the divide and conquer problem solving strategy, only the divide part is already done. The conquering is relatively easy compared to tracking down the cause of test failures when many classes are being exercised in a test.

My experience was that our mock based unit tests caught about 98% of the code problems before the code was ever committed to source control. The integration tests caught about another 1% beyond that (almost always because of a flaw in the mock-based testing) and manual testing caught the other 1%.

假设配置一个Webapp的开发环境:

下载editplus,解压缩、安装到某目录。
建立Webapp的部署目录,如下图：

下载ant,解压缩,设置环境变量ant_home指向刚才解压缩的目录,
来到项目目录/src下,新建一个文本文件,加入以下编译内容

具体就不解释了，不明白的就查资料看看~
把文件改名为build.xml

在同一目录下,建立一个make.bat文件,用记事本打开，加入
%ant_home%/bin/ant

以上编译的准备工作已经完成，下面就把它们集成到editplus中去:

1、添加新的外部命令行执行程序
打开editplus(废话),点
'Tools' -> 'Configure User Tools'... ->Add Tool(按钮)->Program
填下面的参数:

Menu text:随便什么，比如 "编译整个工程"
Command:点后面的'...'按钮，选择刚才的make.bat
Argument:参数,留空就行
Initial directory:起始目录，一般是当前目录。点后面的按钮,选'file directory'就行。

下面把Capture output 打上勾，以捕捉ant编译过程的输出.
点旁边的'Output Pattern',去掉'Use default output pattern'的勾,点下面的下三角按钮,选"java/gcc"
这样就能在输出报错时，双击有行号提示的地方，页面就会直接跳转到出错行。

按下面的带绿勾的OK按钮就完成了，刚才配置的工具就出现在Tools菜单的最底部了。

现在用editplus在src目录下随便建个源文件，然后运行刚才设置的工具,OK，大功告成!
no more jb,no more Eclipse,no more netbeans,no more idea,hahaha......

另：把Tools - > Preference - > General  -> Reload working file on startup 打上勾，可以省去很多打开关闭文件的时间。

就这样了，祝大家用得开心，，还有，editplus只有30d的共享版哦，嘿嘿。。。