|
锁定老帖子 主题：你们公司单元测试吗?
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-01-14
dhj1 写道 gigix 写道 dhj1 写道 再说必定失败的事,做不做不是由你定的!
这个……也许你不能决定做什么事，但至少可以决定你自己不做什么事。要是你连这点权力都不给自己，那就怨不得天怪不得人了。 跑题……有CVS比没有要高效，有单元测试比没有要高效，这个是毫无疑问的。至于说“程序员水平不一”，我推荐一篇blog给大家看 http://jroller.com/page/obie?entry=undisciplined_please_stop_writing_software 我确实不如你这么理论深厚,懂这么多! 下一个疯狂的为期一月的开发就快要在一周到两周内开始. 工期从我评估的开发时间压缩了三倍. 
我得尽可能按时交差. 差不多半年没有疯狂的日子了,现在又要来临了! 在这个项目中,我不会懂什么是测试用例........ 并且浪费了很多口水,为的是砍掉点什么需求中不是太实用的东西. 所以说，过什么样的生活，很大程度上还是你自己选的。 |
| 返回顶楼 | |
|
发表时间：2006-01-14
dhj1 写道 一个好的软件,有正规的文档,测试用例.
好的软件是要有投入的.时间,金钱等,这些是成本. 当公司的成本投入很少时,就不能产生好的软件. 所以,你不得不去掉测试用例,少写文档. --- 就是这么简单! 所以,是不是写测试用例,看公司对这个项目的投入成本决定. 不是理论上该不该的问题! 当公司投入成本不足时,你不能有测试用例,有文档,但是没有软件.所以得反过来! that is why I (actually, Obie) said "un-disciplined? please stop writing software". garbage in, garbage out, not SOFTWARE. |
| 返回顶楼 | |
|
发表时间：2006-01-14
dhj1 写道 gigix 写道 that is why I (actually, Obie) said "un-disciplined? please stop writing software". garbage in, garbage out, not SOFTWARE. I am surprised !!!!! I am bargaining a task to write a document of software from Taiwan. 这是真的,这是一个已经完全完成的软件,没有一个文档. 任何一个电子工程师都知道，没有校验电路只有功能电路，那不叫一张产品电路板，那只是玩具。把一堆无法理解无法维护的代码叫做软件，把undisciplined code monkey叫做程序员，所以我们没有理由抱怨自己的生活不那么理想。所谓自作孽。 |
| 返回顶楼 | |
|
发表时间：2006-01-14
个人经验, 让一个新入行的人,使用TDD方式开发,
要比让一个有些工作经验的人容易. 至于"水平不一"的问题,基本的TDD根本不需要什么 水平.水平高的人,知道怎么去分割问题,逐步解决, 所以他们并不太需要TDD. |
| 返回顶楼 | |
|
发表时间：2006-01-15
单元测试不仅仅是公司的事情,这是一个好的个人习惯
|
| 返回顶楼 | |
|
发表时间：2006-01-15
一蓑烟雨任平生 写道 把公司的问题放在一边，先看看自己在开发的时候是否做了单元测试，代码质量是不是得到大家的认可。
我认为，单元测试是属于设计范畴的。项目和公司的架构和设计摆在那里，很难进行测试。他们设计的时候就只想着两条了，1 接口尽量的好用，2 尽量模块化，这样好分工。第一条使得代码测试和重构难度加大，第二条引入了大量的重复代码。 现在项目进入测试阶段了，很多bug才暴露出来，很多类都得做很仔细的调试和检查。一切都得靠IDE调试，因为谁都没有功夫和兴趣去搞个测试框架，没的办法。 |
| 返回顶楼 | |
|
发表时间：2006-01-15
dazuiba 写道 1 接口尽量的好用，2 尽量模块化
why these guidelines will cause unit-testing hard? |
| 返回顶楼 | |
|
发表时间：2006-01-15
gigix 写道 dazuiba 写道 1 接口尽量的好用，2 尽量模块化
why these guidelines will cause unit-testing hard? 所以，设计时应尽量符合OO的原则。 而我们往往忽视这些基本准则。 即使，有的时候对外接口不能改变，此接口又难以执行单员测试，应该将此接口的实现分离成几小步，每一小步实现都应该是易于测试的。所以，重构的威力是巨大的。 即使不能 design --> unit test --> coding 也应该 design -->coding --> unit test --> refactor --> unit test |
| 返回顶楼 | |
|
发表时间：2006-01-15
JJYAO 写道 gigix 写道 dazuiba 写道 1 接口尽量的好用，2 尽量模块化
why these guidelines will cause unit-testing hard? 所以，设计时应尽量符合OO的原则。 而我们往往忽视这些基本准则。 即使，有的时候对外接口不能改变，此接口又难以执行单员测试，应该将此接口的实现分离成几小步，每一小步实现都应该是易于测试的。所以，重构的威力是巨大的。 即使不能 design --> unit test --> coding 也应该 design -->coding --> unit test --> refactor --> unit test Actually, writing unit test makes you think (or, design). For example, with TDD method, you can hardly write tight-coupled code, because it's difficult to write test for them. That's why I always say that TDD does not slow down your development. Without TDD, do you spend all the time on coding? Absolutely no. Still lots of time spent on thinking and designing, however you don't have an approach to record the result of thinking. TDD is something makes you think accurately, and record the result, and prove it again and again. |
| 返回顶楼 | |
|
发表时间：2006-01-15
万千理由也不能成为“不作单元测试“的依据。
作不作单元测试已经不值得讨论，反而，值得讨论的是怎么作有效单元测试。 也可以讨论所谓集成单元测试，纯粹单元测试....等等之分，现在，看到这么多单元测试的名词，可是很容易让人犯晕的。 看看单元测试的写法和设计，就知道高低手之分了，最近我很遗憾的发现自己还是单元测试的低手。 如果有人跟我说“要不要单元测试“?如果说因为逻辑简单不必测那也就罢了，如果仅仅因为时间不够作为原因，这是绝绝对对不允许的，如果硬是要在时间上作百般托词，那么，就没有讨论的必要了。 道不同不相为谋。 记忆中比较深刻的是，去一个国营单位技术中心作培训，里面有几十位一直搞技术的老手，我们当时让他们练习写单元测试的代码，练了几次，他们大多觉得这些代码是多余的，因为要做一个功能上的扩展，多于早已经熟悉此行业的人来说，华1-2天就可以搞定了，可是却要花这么多时间在这些不是真正能够在产品上运作的测试代码上工作，他们觉得浪费时间，因为总体来说，他们要考虑怎么写测试，（而即使不用写测试，他们脑子里面都清清楚楚知道该如何写那些代码来完成那个功能。） ，加上这个测试的代码，他们要花多1天/半天的时间来写。 他们觉得这样的开发模式是否合理。 诸位，如果你们面对这样的质询，你们该如何回答呢？ （当时，我记得我用很高的音量站起来跟满满一屋子的人说了几分钟的话，这些话几乎都是你来我往的以质询的方式针锋相对。虽然我不知道他们是否真正理解单元测试在软件开发模式中起到如何重要的作用，但是我觉得我已经让他们不能回答我的质询，即使他们心里还是疑惑或者不理解） |
| 返回顶楼 | |
