明天打算l那些组件所有public的方法写上测试用?-虽然花时间给别h的代码写试是极为无聊的行ؓQ但是现在我也认了，不能再这h心吊胆得写代码和手工试了，宁可׃一个上午甚x多的旉来写用例搭徏环境。Rod Johnson说得Ҏ?牛仔式真是编E害死：满天飞的工厂模式、单例、静态变量，什么注释都没有的监听接?---最重要的是Q没有测试用?-乃还程序员吗？知道老子׃多少旉来拜M攚w构step in,step over您的"大作"Qholy shit.
where the amazing happens 2007-07-17 21:10 发表评论
]]>springframework.org论坛里有条评论，译q来大概是_srcpE序说到?是用几个jar和配|文件把你的swing应用l织h的有着复杂的设计结构的xx"Q好吧我不理解ؕ译Q，说vswingQؓ了兼个方面的因素(主要是concurrency)Qswing的开发者们不得不让swing的用者们在一个迂回曲折的环境中编写他们的应用。这好像在一座庞大的金字塔内部观察它的徏{结构一P你会发出阵阵惊叹Q也会绉L头迷惑不?-开始的时候后者是q远多过前者的。回q来看看现在如火如荼的web开发，xQweb开发是不是在走10?0q前的老\Q什么才是程序的真谛呢？
接下来准备学习一Ҏ据挖掘方面的知识Q具体点是语义分析。因为公司在数据采集q方面还相当原始的spider+手工收割Q和st谈到q个时也提到个可选的ҎQ天知道那个看上M良少q一L家伙脑袋里到底装了多东ѝ好了，q周打算拖拖拉拉地把自动更新updater写完Q顺便看看有没机会弄成一个通用的updater。第一期的业务逻辑不复杂，所以也暂时没我什么事Q正好可以一只脚站在门外l心瞅瞅Q其他等评估l果出来了再说。刚才收信时候看到有?4Loffer letterQ密密麻ȝ英文搞得foxmail都把它丢到垃圄里去了?br/>
where the amazing happens 2007-06-19 22:34 发表评论
]]>原题要求用javaQ用python只是Z方便。用回溯法快Q但是还是坚持用遍历林来写Q这也是面试时没惛_的思\Q呵呵，我就是自N烦的石头性格?/p>
最先想到用无向q通图q行深度优先搜烦Q但是没有考虑到结束条件。对于N个待排列的数字，每个节点都有N-1个出口和入口Q而用树状l构每个节点只有一个父节点Q存在递归q回的条件。但是这个方法的实用性只限制在当排列数很（N < 8Q时。当N>8时算法消耗的旉明显增加(一?*7*6*5*4*3*2*1=40320U组?Q当N>1000?当然Q这U情冉|不敢惛_?׃辑ֈpython的递归极限。所以真正如果要q点什么的?当然Q高中生都知道全排列?2张扑克牌出来排一下结果集是个天文数?Q这昄不是个好法?/p>
#coding=utf-8# 数字全排?/span># Chris Zheng 2007-06-05import sys, os#待排列的数字NUMS = [1,2,3,4,5,6]#l果集合results = []EXCLUDES = ( lambda a,b,nums:abs(nums.index(a) - nums.index(b)) == 1, #a,b是否盔R lambda a,b,idx_a,idx_b,nums:nums.index(a) == idx_a and nums.index(b) \ == idx_b #a,b是否同时W合特定位置)# 3?不能盔R ?在第1?不能在第7EXT_PARAMS = ( (3,4,NUMS),(2,6,1,7,NUMS))#查排除条?/span>def __check_conditions(nums): matchs = False for f in EXCLUDES: for params in EXT_PARAMS: try: params[-1] = nums matchs = f(*params) if matchs: return matchs except Exception:continue return matchs#树节?/span>class node(object): def __init__(self, n): self.value = n self.parent = None self.children = [] def __eq__(self,other): return self.value == other.value def __str__(self):return str(self.value)#L?/span>def get_all(nums): trees = [] for n in nums: trees.append(create_tree(node(n))) for t in trees: walk_tree(t) global results #qo条g return (r for r in results if not __check_conditions(r))#生成l果?/span> def create_tree(root): parent_elements = __parents(root) if len(parent_elements) == len(NUMS)+1:return root nums = (nums for nums in NUMS if node(nums) not in parent_elements) for k in nums: c = node(k) c.parent = root root.children.append(create_tree(c)) return rootdef __parents(node): parent_elements = [node] while node.parent: parent_elements.append(node.parent) node = node.parent return parent_elements#遍历l果?/span>def walk_tree(root): if root.children: for n in root.children: walk_tree(n) else: k = [root.value] p = root.parent while p: k.append(p.value) p = p.parent k.reverse() results.append(k)#试输出if __name__=='__main__': rs = get_all(NUMS) f = open('results.txt','w') for k in rs: f.write(str(k)+'\n') f.close()
.
where the amazing happens 2007-06-05 14:47 发表评论
]]>where the amazing happens 2006-09-25 20:40 发表评论
]]>where the amazing happens 2006-06-18 04:51 发表评论
]]>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 “issues?with using mocks to support unit testing. I’m 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’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). ?/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’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%.
where the amazing happens 2006-06-04 18:53 发表评论
]]>下蝲(附带eclipse的工E文? http://zqc53.512j.com/others/JailsReleaseWithEclipse.rar
where the amazing happens 2006-05-06 00:27 发表评论
]]>