This chapter is exiting, but also making people to doubt. Traditional views believe that the cost of changing a program rises exponentially over time. And it’s better to make decisions at the early stages. But Kent Beck believes that we can make the cost of change so low that this cost-time curve can be a …
这次的TDD不是那么严格，我并没有先写测试用例再写代码，而只是把单元模块写好之后立即写单元测试，同时注意维护一套Test Suite，确保单元测试的覆盖程度，并作为代码重构后的验收标准。 总体上，搞了一段时间之后，我觉得代码质量比较高（Bug率较低），但效率很难让人满意，并且我也并不那么快乐。 1.写单元测试几乎成了一种负担。 a. 手动生成测试类太辛苦太无聊。不过后来发现了Fast Code Plugin，情况有所改观 b. 写一个代码立即写一个测试类，不符合批量作业的原理：你的头脑要不停地从开发者到测试者两者之间切换，效率低下，而且很让人沮丧；当重构发生时，单元测试也要重构，这更加让人不胜奇烦。后来我想的办法是先把一定的代码全部写好之后写测试来测，为了不遗漏，我会在写代码时做个标记(比如throw UnsupportedOperationException)，然后在测试时按这些标记找到应测类。 c.单元测试不是那么好写。我的经验发现单元测试的代码量往往会超过被测代码。比如说，EasyMock的三步曲还是不够简洁，用JAVA写测试数据也挺麻烦。最终我发现，单元测试使开发周期加倍。 2.TDD提倡的自底向上的设计思路也会搞得很低效。 自底向上的设计，即先写代码再重构，的确可以让你的脑子免于很多思考，先把车开到山前，到了山前再开路。但我的体会就是“山前开路”发生的太频繁了，而且“返工”太多了。9点开好的一条临时小径，11点就得被重构掉，加上它的测试用例，再考虑到CVS等因素，反复重构非常低效。 所以我后来觉得，还是先设计为好。 不过，虽然有上面那些问题，但我觉得TDD仍是一条应该坚持走下去的路。虽然首次开发时时间较短，但由于Test Suite的存在，日后的维护代价会轻很多。
To solve this problem, you should: // If you define one matcher for an expected argument, you need to define them for all the arguments! expect(service.findFoos(isA(FooSearchCriteria), eq(maxResults), aryEq(sortCriteria))).andReturn(expectedResult) See http://www.nearinfinity.com/blogs/scott_leberknight/the_n_matchers_expected_m.html
PowerMock is a Java framework that allows you to unit test code normally regarded as untestable. http://code.google.com/p/powermock/
Problem: Time is limited and requirements are always at changing. Solution: Elimination scopes and implement the first things first. How does it work? 1.Phasing means we don’t have to do too many things in a hurry. 2.First things first means we can usually deliver the most important things the customers need.
How does XP deal with the problem of Risk in software development? 1. No deadline fails <= Only highest functionalities are implemented <= It’s easy to finish small problems and small tasks in a short cycle of releases and iterations, 2. Project will not be canceled. <= Smallest release that makes …
XP is a light-weight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. It promises to 1.Reduce project risk 2.Improve responsiveness 3.Improve Productivity 4.Add Fun What are they? 1.Pair Programming 2.Unit Testing 3.Refactoring 4.The simplest thing that could possibly work 5.Metaphor(Refine the arch all …
Jester是一款用来检查测试覆盖性的工具，它与其它类似工具的不同之处在于：其它测试工具的检测指标是每行被测代码是否被执行，而Jester则是通过一种奇怪的模式：改变一下被测代码的逻辑，执行一下测试用例，如果仍能全部通过，则表示测试有遗漏。 这种逻辑很古怪，但仔细想想就会发现它的合理之处，本文就不提了。 但是这种逻辑比起传统逻辑，即检测每行被测代码是否被执行的逻辑，到底强在哪里呢？一般来说，如果每行代码都被执行到了，那测试自然就完备了。 我被这个问题几乎搞得睡不着觉。由于智商太低，数理逻辑也不扎实，怎么想也想不出来。就当我要放弃的时候，灵感终于来了，我终于明白: 传统工具虽然可以找到未被测试的代码，但未必能找到未被测试的程序逻辑；为什么呢？因为有的逻辑是隐式的，而不是通过代码显式声明的。 举一个例子就能说明这个问题： 测试用例： List resultList = ….; testee.do(3,resultList); assertTrue(resultList.size() == 1) 被测代码： //Testee public void do(int index,Collection resultList){ if(index >= 3){ resultList.add(new Object()); } } 被测代码只有一个If/Then逻辑。如果用传统检测工具来检查，那覆盖率肯定是100%，一切都很好。 但用jester来检查，jester就会报错。因为把 if(index >= 3) 变成 if(true || (index >= 3))后，测试用例仍然可以绿色通过。 这是为什么？ 因为jester期望测试用例能够考虑到 index < 3的情况。只有考虑到了index < 3的情况，在 if(index >= 3) 变成 if(true || (index >= …
I’ve been reading this book of TDD, written by Kent Beck Overview 1.Goal: Clean Code that Works 2.Benefit: Manage fear during Programming 3.Three Steps: a. Write a test case in advance of writing code. Of course it won’t work, so it’s RED b. Try your best to make your test …
我的观点和考虑到的地方几乎和他一样。但当我在javaeye论坛里表达这些观点时，别人反而觉得好笑！ Remember that documentation should serve to: 1. Provide a contract for objects and methods. Test cases for an object are also valuable specifications, and documentation and test cases should be kept synchronized. 2. Save developers the trouble of needing to read code before they use it. There should be no need to …