|
锁定老帖子 主题：吹弹得破是重回一人犯错，全家光荣的老路
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-04-20
江南白衣 写道 算了，这话题 close掉算了，继续也讨论不出什么来。
除非我们这里有人可以直达天听，建议老rod把这个处理方式搞成可选的。 据说Hivemind的作者曾经在找rod谈过几次这个问题，但是rod有自己的想法 他认为POJO是必要的，所以没有必要为了部署而增加新组件模型到POJO上，so,that's all |
| 返回顶楼 | |
|
发表时间：2006-04-20
江南白衣 写道 gigix 写道 “集成测试的时机可以由用户选择”，没错的，Spring的配置出错也不会影响你编译和run unit test cases亚。
绝对影响unit test!!!!!, 因为我们的TestCase基类是load all application-context-*.xml的，除非你很仔细的为每个test case指定用到的所有application-context-xxxx.xml, 而且隔壁那条友没把一些main的applicaiton-context弄错。 关于这个问题，就是白衣你的不对了 rod也曾多次警告要为unit test写专门的application-context－*.xml 这来自于decouple环境的依赖，进行纯粹的unit test 而你说的那种load all context的，就不能叫单元测试了吧 |
| 返回顶楼 | |
|
发表时间：2006-04-20
看到robbin提起easymock，我倒想说两句，spring提供的mock包跟easymock有异曲同工之妙，只不过，它需要自己写mock实现，而不想easymock那样，在testcase里面就往里写返回值
不过各有利弊，我是不喜欢easymock那样写法 |
| 返回顶楼 | |
|
发表时间：2006-04-20
cm4ever 写道 gigix 写道 请避免一概而论。这“一个文件”，要分应用的内部文件还是外部文件，是应用的一部分还是业务的一部分。如果是应用程序本身出了错，尽早发现尽早修复是我能想到的最好办法。这是你现有功能中的bug，你为什么要想把它掩盖起来？ 另外，我很反对随便打比方。为了证明打比方的随意性和无价值，我也给你打个比方。比如说你出门之前就要检查机票身份证手机钱包笔记本行李箱是不是都带好了，要是走到机场再检查发现没带机票，最起码你得麻烦，更大的可能性是要误飞机。 我的比方考虑了同步性质，但你的没有。你的是单线作业，只是一个模块。我们讨论的是多个模块并存的状况。 其实这个人出门之后他可能做多件事，最后才是去机场。难道因为他到了机场才发现没带机票不能上飞机，就不能做其他事情了？他还是可以在车上电话订束玫瑰给女朋友。再跟生意伙伴通电话，顺便用PDA订好日程，这些都不影响嘛。 就象搂主所说的一样：甲犯的错误，为什么要乙一起跟着受罪？ 一个模块错误，就报错好了，但其他模块还可以继续运行。这并不冲突。 这个问题问得很好。如果你在项目里做了great job，项目大成功，你的同事会不会跟着一起领奖金？如果你的同事在项目里搞一堆狗屎，搞得不能按时交付，你要不要跟着一起加班？ |
| 返回顶楼 | |
|
发表时间：2006-04-20
我建议把这个帖子移到敏捷开发方法那个版去
所谓团队就应该是一损俱损,一荣俱荣 组织团队的第一件事情就是告诉所有人,任何一个问题都是团队的问题,任何一种创新都是团队的创新 任何一个问题都是团队的问题,产生这个问题的人不应该感到羞愧，所以有任何问题都可以提出来、摊开来，深入地研究下去，任何一个问题都是团队的问题，所以每个人都愿意帮助队员去解决，因为这本来也是他的问题 任何成功都是团队的成功，所以每个人都愿意把自己的东西教给别人，愿意自己去创新，愿意和别人去pair，愿意对别人的创新和改进提出更多自己的建议 有趣的是,在这样的团队里越来越少的相互扯皮,有能力的人越来越能体现出他的优势来,而整个团队的人趋向于向水平最高的人靠近,而不是相反 |
| 返回顶楼 | |
|
发表时间：2006-04-20
gigix 写道 这个问题问得很好。如果你在项目里做了great job，项目大成功，你的同事会不会跟着一起领奖金？如果你的同事在项目里搞一堆狗屎，搞得不能按时交付，你要不要跟着一起加班？ 我同意你管理上的方式，但是不同意对程序这样用。 看来对于这个问题两种分支看法是一定存在的，两种处事哲学？ 我想有空还是改一个XXX的可容错版本，喜欢用哪个的用哪个。 |
| 返回顶楼 | |
|
发表时间：2006-04-20
robbin 写道 你这不叫做unit test，叫做集成测试。单元测试是不初始化spring容器滴～
有空不妨学学easymock吧。 听Robbin老大的话，回去翻了一下Appfuse, Spring 的Petlinc Sample和 <Professional J2ee with Spring>的BoxOffice Sample 的test code，发现是这样的： 1.Boxoffice纯粹EasyMock，完全隔离一切。 2.Appfuse的dao层测试跑load all ApplicationContext， 而Service层和Web层，因为最新版改用了JMock, 而JMock是很变态的要求Test必须继承于它，不能再继承于Spring提供的那些TestCase基类，所以也不跑Application Context了。而旧版EasyMock的时候是跑的，有<spring live> 为证。 3.Petlinc 是继承于 AbstractTransactionalDataSourceSpringContextTests 的，跑。 对比结果，BoxOffice的纯EasyMock是最酷的。 但除非有与IDE良好结合的插件负责自动生成，否则代码量相当高-- 又要自己用set设置所有对象，又要录制所有出场对象的方法执行结果，如果对象关联多的话，这工作，是相当壮观。 而且，这种离实际环境很远的纯mock testCase只能用作分块分层的开发手段，即使过了，也不可以安心回家睡觉吧，最后不还是要有一套集成的test case测过了才安心么？ 看来TW的XP水平真的非常高，和我们差距太远了:( SpringSide现在的方式比较懒，首选是load all， 让Spring的基类搞定一切对象管理，默认也使用真实对象来完成一切，这样，开发人员的主要精力是编写那些测试校验的代码。 只有需要时，才重载protected String[] getConfigLocations() 限定context file ，手工注入对象，用easyMock去mock对象，录制事件。（见BookManagerMockDaoControllerTest.java） 难道，Pragmatic和Extreme Programing团队真的不再是同义的名词了？ 再BTW.即使用纯mock的ut，开发可以不受隔壁的人干扰了，但万一想看看自己模块心爱的界面，或者想跑一下web层测试时，还是发现因为隔壁的人启动不了应用时，难道不想老rod手下留情，给个option么。 |
| 返回顶楼 | |
|
发表时间：2006-04-20
楼主的问题很多人都有同感, 其实这个问题到现在也没有办法完全解决. 我不认为它和敏捷开发 和编程水平有关系.
过去我尝试过在传统mvc下进行完全独立的组件化开发 结果遇到的最大障碍就是rdb 和 class 越强调面向对象 系统间的关联越多 越难保持模块的独立性. 如果单独的组件 无法做独立运行 做响应的功能测试 性能测试 组件化开发就是瞎吹. 类 关系数据库 本身就不是为了web开发而设计的 更没有考虑过松藕合的问题. 现在用xml框架 xmldb从本质上解决了一些重要的障碍 路才开始越走越宽. 团队精神不是办法 其实这是技术本身的问题. |
| 返回顶楼 | |
|
发表时间：2006-04-20
江南白衣 写道 gigix 写道 “集成测试的时机可以由用户选择”，没错的，Spring的配置出错也不会影响你编译和run unit test cases亚。
绝对影响unit test!!!!!, 因为我们的TestCase基类是load all application-context-*.xml的，除非你很仔细的为每个test case指定用到的所有application-context-xxxx.xml, 而且隔壁那条友没把一些main的applicaiton-context弄错。 我们现在的项目也是这样的。并不是不想分开。 如果团队成员较少的话，这样反而更方便。 到是要求application-context-*.xml中的这个*有很好的划分界限 |
| 返回顶楼 | |
|
发表时间：2006-04-20
winterwolf 写道 楼主的问题很多人都有同感, 其实这个问题到现在也没有办法完全解决. 我不认为它和敏捷开发 和编程水平有关系.
过去我尝试过在传统mvc下进行完全独立的组件化开发 结果遇到的最大障碍就是rdb 和 class 越强调面向对象 系统间的关联越多 越难保持模块的独立性. 如果单独的组件 无法做独立运行 做响应的功能测试 性能测试 组件化开发就是瞎吹. 类 关系数据库 本身就不是为了web开发而设计的 更没有考虑过松藕合的问题. 现在用xml框架 xmldb从本质上解决了一些重要的障碍 路才开始越走越宽. 团队精神不是办法 其实这是技术本身的问题. 每个人必须每个unit自己testt通过，每次commit之前必须进行smoke test，每次update下来做一次smoke test，这是必须做的事情，没有什么好打折扣的。 在时间比较短的时候，可以跑所有的测试(smoke test = all tests)，如果项目进行到一定的程度,smoke test可以是容器的加载、数据库sessionFactory生成等等一些最重要的全局性相关的测试 |
| 返回顶楼 | |
