锘??xml version="1.0" encoding="utf-8" standalone="yes"?>
A article from Technoetic
- Posted in Software Dev., Agile by Steve Bate
I recently read a blog entry with criticisms of mock-based testing. The author raised several 鈥渋ssues鈥?with using mocks to support unit testing. I鈥檓 commenting here since the author has closed comments on the original blog entry.
Issue 1: Poor integration tests, as everything is being tested in isolation
I鈥檝e had good experience with mock-based testing. However, it鈥檚 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鈥檚 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鈥檛 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 鈥渦nit鈥?is a class or small group of tightly coupled classes. For others, it鈥檚 a large portion of the software product. Most agile developers seem to call every test they write a unit test. It鈥檚 become so confusing for some teams that I鈥檝e seen terminology like 鈥渋ntegration 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.
鈥淚鈥檝e 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鈥檚 more code to maintain). 鈥?/p>
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鈥檇 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鈥檛 add a significant maintenance overhead. Most effort is spent implementing the interface. The time writing the interface itself (or extracting it using an IDE鈥檚 refactoring tools) is negligible.
My Conclusions
In almost every case, I see the 鈥渟implicity鈥?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鈥檚 often very slow for large numbers of tests. Some teams are using continuous integration tools like Cruise Control to run their 鈥渦nit 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鈥檝e seen and heard.
I鈥檝e 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鈥檛 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鈥檚 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%.
鍋囪閰嶇疆涓涓猈ebapp鐨勫紑鍙戠幆澧?
涓嬭澆editplus,瑙e帇緙┿佸畨瑁呭埌鏌愮洰褰曘?BR>寤虹珛Webapp鐨勯儴緗茬洰褰?濡備笅鍥撅細(xì)
涓嬭澆ant,瑙e帇緙?璁劇疆鐜鍙橀噺ant_home鎸囧悜鍒氭墠瑙e帇緙╃殑鐩綍,
鏉ュ埌欏圭洰鐩綍/src涓?鏂板緩涓涓枃鏈枃浠?鍔犲叆浠ヤ笅緙栬瘧鍐呭
鍏蜂綋灝變笉瑙i噴浜?jiǎn)锛屼笉鏄庣櫧鐨劄鏌ヨ祫鏂欑湅鐪媬
鎶婃枃浠舵敼鍚嶄負(fù)build.xml
鍦ㄥ悓涓鐩綍涓?寤虹珛涓涓猰ake.bat鏂囦歡,鐢ㄨ浜嬫湰鎵撳紑錛屽姞鍏?BR>%ant_home%/bin/ant
浠ヤ笂緙栬瘧鐨勫噯澶囧伐浣滃凡緇忓畬鎴愶紝涓嬮潰灝辨妸瀹冧滑闆嗘垚鍒癳ditplus涓幓:
1銆佹坊鍔犳柊鐨勫閮ㄥ懡浠よ鎵ц紼嬪簭
鎵撳紑editplus(搴熻瘽),鐐?BR>'Tools' -> 'Configure User Tools'... ->Add Tool(鎸夐挳)->Program
濉笅闈㈢殑鍙傛暟:
Menu text:闅忎究浠涔堬紝姣斿 "緙栬瘧鏁翠釜宸ョ▼"
Command:鐐瑰悗闈㈢殑'...'鎸夐挳錛岄夋嫨鍒氭墠鐨刴ake.bat
Argument:鍙傛暟,鐣欑┖灝辮
Initial directory:璧峰鐩綍錛屼竴鑸槸褰撳墠鐩綍銆傜偣鍚庨潰鐨勬寜閽?閫?file directory'灝辮銆?/P>
涓嬮潰鎶奀apture output 鎵撲笂鍕撅紝浠ユ崟鎹塧nt緙栬瘧榪囩▼鐨勮緭鍑?
鐐規(guī)梺杈圭殑'Output Pattern',鍘繪帀'Use default output pattern'鐨勫嬀,鐐逛笅闈㈢殑涓嬩笁瑙掓寜閽?閫?java/gcc"
榪欐牱灝辮兘鍦ㄨ緭鍑烘姤閿欐椂錛屽弻鍑?yán)L湁琛屽彿鎻愮ず鐨勫湴鏂癸紝欏甸潰灝變細(xì)鐩存帴璺寵漿鍒板嚭閿欒銆?/P>
鎸変笅闈㈢殑甯︾豢鍕劇殑OK鎸夐挳灝卞畬鎴愪簡(jiǎn)錛屽垰鎵嶉厤緗殑宸ュ叿灝卞嚭鐜板湪Tools鑿滃崟鐨勬渶搴曢儴浜?jiǎn)銆?/P>
鐜板湪鐢╡ditplus鍦╯rc鐩綍涓嬮殢渚垮緩涓簮鏂囦歡錛岀劧鍚庤繍琛屽垰鎵嶈緗殑宸ュ叿,OK錛屽ぇ鍔熷憡鎴?
no more jb,no more Eclipse,no more netbeans,no more idea,hahaha......
鍙︼細(xì)鎶奣ools - > Preference - > General -> Reload working file on startup 鎵撲笂鍕撅紝鍙互鐪佸幓寰堝鎵撳紑鍏抽棴鏂囦歡鐨勬椂闂淬?BR>
灝辮繖鏍蜂簡(jiǎn)錛岀澶у鐢ㄥ緱寮蹇?jī)锛屽Q岃繕鏈夛紝editplus鍙湁30d鐨勫叡浜増鍝︼紝鍢垮樋銆傘傘?/P>