blocks|key|1491981|text|我们已经用确凿的证据证明，可以在没有单元测试的情况下编写糟糕的软件。我相信甚至有证据表明单元测试的软件质量很差。但这不是重点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1491982|单元测试或测试驱动开发(TDD)是一种设计技术，而不是一种测试技术。由编写的测试驱动的代码看起来与非编写的代码完全不同。|1491983|尽管这不是你的问题，但我想知道这是否真的是最简单的方式来回答可能被问错的问题(并带来可能被其他报告质疑的证据)。即使你为你的案件找到了确凿的证据--其他人可能也会找到不利于你的确凿证据。|1491984|确定技术人员应该如何工作是统计人员的业务吗？他们是否在所有情况下都提供最便宜的工具，因为他们认为你不需要更昂贵的工具？|1491985|这种争论要么是基于信任(敏捷团队的基本价值之一)赢得的，要么是基于获胜一方的角色权力而失败的。即使TDD支持者基于角色权力获胜，我也会将其视为失败。|1491986|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

We've demonstrated with hard evidence that it's possible to write crappy software without Unit Testing. I believe there's even evidence for crappy software with Unit Testing. But this is not the point.

Unit Testing or Test Driven Development (TDD) is a Design technique, not a test technique. Code that's written test driven looks completely different from code that is not.

Even though this is not your question, I wonder if it's really the easiest way to go down the road and answer questions (and bring evidence that might be challenged by other reports) that might be asked wrong. Even if you find hard evidence for your case - somebody else might find hard evidence against.

Is it the business of the bean counters to determine how the technical people should work? Are they providing the cheapest tools in all cases because they believe you don't need more expensive ones?

This argument is either won based on trust (one of the fundamental values of agile teams) or lost based on role power of the winning party. Even if the TDD-proponents win based on role power I'd count it as lost.

blocks|key|1707115|text|是。这是NCST的Boby+George和Laurie+Williams的一项研究的link，以及Nagappan等人的another。我敢肯定还有更多。威廉姆斯publications博士的测试可能为找到他们提供了一个很好的起点。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1707116|编辑上面两篇专门引用TDD的论文，显示采用TDD后初始开发时间增加了15-35%25，但预发布缺陷减少了40%25-90%25。如果你不能获得全文版本，我建议你使用Google+Scholar，看看你是否可以找到一个公开的版本。|1707117|entityMap|0|LINK|mutability|MUTABLE|url|http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf|1|http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf|2|http://collaboration.csc.ncsu.edu/laurie/publications.html#Testing|3|http://scholar.google.com/^0|16|4|0|1O|7|1|29|C|2|0|24|E|3|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]|$A|X|B|Y|1|Z]|$A|10|B|11|1|12]]|C|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|F|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]|R|$5|I|J|K|C|$L|S]]]]

Yes. This is a <a href="http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf" rel="noreferrer">link</a> to a study by Boby George and Laurie Williams at NCST and a <a href="http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf" rel="noreferrer">another</a> by Nagappan et al. I'm sure there are more. Dr. Williams <a href="http://collaboration.csc.ncsu.edu/laurie/publications.html#Testing" rel="noreferrer">publications</a> on testing may provide a good starting point for finding them.

[EDIT] The two papers above specifically reference TDD and show 15-35% increase in initial development time after adopting TDD, but a 40-90% decrease in pre-release defects. If you can't get at the full text versions, I suggest using <a href="http://scholar.google.com" rel="noreferrer">Google Scholar</a> to see if you can find a publicly available version.

blocks|key|1707160|text|“我必须帮助其他程序员，更重要的是，管理中的计时器，所有花在学习测试框架、编写测试、保持更新等方面的额外时间都会有回报，甚至更多。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1707161|为什么？|1707162|为什么不悄悄地、谨慎地去做呢？你不需要一次做完所有的事情。你可以用很小的片段来做这件事。|1707163|框架学习只需要很少的时间。|1707164|编写一个测试，只需要很少的时间。|1707165|没有单元测试，你所拥有的就是对你的软件的一些信心。对于一个单元测试，您仍然有信心，并证明至少有一个测试通过。|1707166|这就是所需要的。没有人需要知道你在做什么。就这么做。|1707167|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

" I have to convice the other programmers and, more importantly, the bean-counters in management, that all the extra time spent learning the testing framework, writing tests, keeping them updated, etc.. will pay for itself, and then some."

Why?

Why not just do it, quietly and discretely. You don't have to do it all at once. You can do this in little tiny pieces.

The framework learning takes very little time.

Writing one test, just one, takes very little time.

Without unit testing, all you have is some confidence in your software. With one unit test, you still have your confidence, plus proof that at least one test passes.

That's all it takes. No one needs to know you're doing it. Just do it.

blocks|key|1707234|text|这里有一个关于一个人从内部改变他的公司的很棒和有趣的读物。它并不局限于TDD。http://jamesshore.com/Change-Diary/注意到，他在相当长的一段时间内没有说服“豆子计数器”，而是采取了“游击战术”。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1707235|entityMap|0|LINK|mutability|MUTABLE|url|http://jamesshore.com/Change-Diary/^0|13|Z|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Here's a great and entertaining read of a guy changing his company from within. It's not limited to TDD. <a href="http://jamesshore.com/Change-Diary/" rel="noreferrer">http://jamesshore.com/Change-Diary/</a> Note that he didn't persuade the "bean counters" for quite some time and did "guerilla tactics" instead.

blocks|key|1707304|text|如果你也对反对单元测试的证据感兴趣，这里有一篇经过仔细研究和深思熟虑的文章：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1707305|Why+Most+Unit+Testing+is+Waste+By+James+O+Coplien+(lean+and+agile+guru)|offset|length|1707306|entityMap|0|LINK|mutability|MUTABLE|url|http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf^0|0|0|1Z|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

If you are also interested in evidence against unit testing here is one well researched and thought out article:

<a href="http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf" rel="noreferrer">Why Most Unit Testing is Waste By James O Coplien (lean and agile guru)</a>

Unit testing sounds great to me, but I'm not sure I should spend any time really learning it unless I can convince others that is has significant value. I have to convince the other programmers and, more importantly, the bean-counters in management, that all the extra time spent learning the testing framework, writing tests, keeping them updated, etc.. will pay for itself, and then some.

What proof is there? Has anyone actually developed the same software with two separate teams, one using unit testing and the other not, and compared the results? I doubt it. Am I just supposed to justify it with, "Look it up on the Internet, everybody's talking about it, so it must be the right thing to do"?

Where is the hard evidence that will convince the laymen that unit testing is worth the effort?

Is there hard evidence of the ROI of unit testing?

单元测试对我来说听起来很棒，但我不确定我是否应该花任何时间真正学习它，除非我能说服别人它有重要的价值。我必须说服其他程序员，更重要的是，说服管理部门的会计人员，所有额外的时间都花在学习测试框架、编写测试、保持更新等方面。将会为自己付出代价，甚至更多。有什么证据呢？有没有人真的用两个不同的团队开发了相同的软件，一个使用单...

问单元测试的ROI有确凿的证据吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单元测试的ROI有确凿的证据吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单元测试的ROI有确凿的证据吗？
EN