blocks|key|119924|text|我会说两倍的时间是一个公平的估计，是的，单元测试总是值得的时间和努力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|119925|然而，我认为花在单元测试上的时间要比以后调试和修复由于缺乏单元测试而导致的错误所花费的时间要少得多。|119926|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I would say that double the time is a fair estimate and yes, unit testing is always worth the time and effort.

However I would contend that the time spent in unit testing is significantly less then the time it would take to debug and fix errors later that resulted from a lack of unit testing.

blocks|key|1525356|text|单元测试还可以用来记录代码库，比如如何使用/调用特定的类/方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1525357|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Unit tests also serve the purpose of documenting your code base, in terms of how do I use/call a particular class/method.

blocks|key|119991|text|我认为，编写自动化单元测试的时间根据您的语言和开发方式而有所不同。例如，使用非常过程化的风格编写C#可能会导致难以开发测试。但是，如果您采用不同的方法，例如使用一些mocking和IOC框架，单元测试时间可以大大减少。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|119992|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would argue that time to write automated unit tests varies based on your language and how you do your development. For example, writing C# with a very procedural style can lead to difficult to develop tests. However, if you take a different approach, say using some mocking and IOC frameworks, unit testing time can drastically be reduced.

blocks|key|1525448|text|我想这要看情况了。您的目标测试覆盖率是多少？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1525449|如果您打算遵循TDD的真正定义，即每一行代码都通过单元测试用例进行测试，那么您可能需要付出巨大的努力。|1525450|但并不一定非得如此|1525451|你可以找到你自己的平衡。|1525452|在我的经验中-我没有发现这可以使时间翻一番-尽管它确实增加了一个因素(20-25%25+?)|1525453|我的意思是-即使你没有单元测试用例-你仍然会手动进行单元测试-对吗？|1525454|随着项目时间的推移，您将看到花在单元测试用例上的时间很容易颠倒过来|1525455|对于客户项目--+IMHO是。希望他们会感谢他们的努力。|1525456|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

I guess it depends... on what amount of test coverage are you targeting

If you intend to follow the true definition of TDD where each and every line of code is tested via unit test cases- you may be looking for huge effort

But it doesn't have to be that

You can find your own balance...

In my experiences- I haven't find this to double the time- though it does add a factor (20-25% ?)

I mean- even if you didn't have unit test cases- you would still do manually unit test it- right ?

Over the time of the project- you will see that the time spent on unit test cases is recvered quite easily

For client projects- IMHO yes. They will hopefully appreciate the effort

blocks|key|1627665|text|关于额外时间的话题，既然你提到你是一个初学者:你越早找到适合你需求的单元测试套件就越好。您还没有提到您正在使用什么语言，但是如果不支持反射(例如C，C%2B%2B+)，设置单元测试工具通常会花费更长的时间，因为您必须实例化TestSuite和测试，并且必须注册测试，等等。当您只想运行几个测试时，这些都是需要学习的东西！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1627666|另一方面，如果您使用的是动态程度更高的语言，例如Python语言，那么只需使用unittest模块创建几个testXXX方法，就可以在几乎不了解单元测试的情况下设置单元测试。|offset|length|style|CODE|1627667|关于第二个问题，设身处地为客户着想--你不想听到你购买的产品已经过了彻底的测试吗？他们(可能)喜欢数字！告诉他们你已经设置了自动化测试，有超过500个单独的测试运行，超过80%25的代码已经以这种方式进行了测试--好吧，只告诉他们真相，但你明白了。它在代码信心方面增加了巨大的价值，坦率地说，我更愿意与能够证明他们知道什么是经过测试的以及什么可能是不可靠的人做生意，而不是仅仅递给我一些东西然后说“已经完成”的人。|1627668|entityMap^0|0|13|8|1H|7|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

On the topic of added time, since you mentioned you're a beginner: the sooner you can find a unit testing suite that fits your needs, the better. You haven't mentioned what language you're using, but if there is no support for reflection (C, C++ for example), it's generally going to take a lot longer to set up the unit testing facilities, because you have to instantiate the TestSuite, and the Test, and you have to register the Test, etc. That's all a lot of stuff to learn when all you want to do is run a couple tests!

On the other hand, if you're using a more dynamic language like Python, for instance, you can pretty much set up unit tests with hardly any knowledge of unit testing by making a few <code>testXXX</code> methods with the <code>unittest</code> module.

Regarding the second question, put yourself in the shoes of the client - wouldn't you like to hear that the product you've bought has been thoroughly tested? They (probably) love numbers! Tell them that you've set up automated testing, there were over 500 individual tests run, over 80% of the code has been tested that way -- well, only tell them the truth, but you get the point. It adds an immense value in the way of code confidence, and frankly I'd rather do business with someone who can demonstrate that they know what has been tested and what might be flaky, rather than someone who just hands me something and says "it's done."

blocks|key|120195|text|您正在测试的内容将决定它需要多长时间。例如，使用MS的数据库单元测试框架为TSQL编写单元测试比编写存储过程花费的时间要长得多，因为这是一个非常手动的测试准备过程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|120196|但是，如果我使用Eclipse或VS2008+for+Java或C#类，并且我只是告诉它创建测试，那么它做测试就会非常快，因为很多繁琐的工作都是为我完成的。|120197|这总是值得的，因为它有助于减少一些可能的bug，但更重要的是，当涉及到复制bug时，您最终将编写这些测试，如果您不将您的类设计为单元可测试的，那么它将需要重构，这可能会引入新的bug，以修复报告的bug。|120198|这是一个重要的事情，你会发现你的函数是不可测试的，所以你最终会重构，这样你就可以做合理的单元测试了。|120199|例如，如果您有一个从数据库中选择的函数，然后对结果执行业务逻辑，那么您如何正确地测试它？它应该是两个独立的函数，其中一个控制器调用获取数据，然后调用执行业务逻辑，因此您将有三个测试，但是，控制器可以转到数据库的模拟，因为您有一个单独的测试来测试数据库层。|120200|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|$]]

What you are testing will determine how long it takes. For example, it takes me much longer to write a unit test for TSQL using the Database unit test framework from MS than it took to write the stored procedure, as it is a very manual process to prepare the test.

But, if I use Eclipse or VS2008 for Java or C# classes, and I just tell it to create the tests, then it is pretty quick to do the tests, as much of the grunt work is done for me.

It is always worth it though, as it helps to cut down on some likely bugs, but, more importantly, when it comes to duplicating a bug you will end up writing these tests anyway, and if you don't design your classes to be unit-testable then it will require refactoring, which can introduce new bugs, in order to fix a reported bug.

That is one important thing is that you will find that you have functions that are not testable, so you will end up refactoring just so you can do reasonable unit tests.

For example, if you have a function that selects from a database, then does business logic on the results, how do you properly test that? It should be two separate functions, with a controller that calls to fetch the data, then calls to do the business logic, so you will have three tests, but, the controller can go to a mock for the database as you have a separate test to test the database layer.

blocks|key|120235|text|对于我的编程，我倾向于只测试我不能直观地查看并知道它会工作的部分代码(有些人会认为这是不够的，但这是无关紧要的)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|120236|我已经用这种方式编程很长一段时间了，我首先使用这些测试来帮助我编写代码。鉴于此，编写测试的时间基本上不会增加我的总体开发时间。如果我跳过编写我做的测试，它“可能”为我节省了10%25的时间。|120237|当我第一次开始使用自动化测试时，我会说写代码的总时间翻了一番是一个公平的估计。但是，随着时间的推移，我已经走到了我不在的地方(几乎没有时间)。老实说，这是你习惯的东西，它成为你设计代码的一部分。|120238|编辑:我想补充的是，有时候编写测试代码仍然会给我的代码增加相当多的时间，有时会增加一倍以上。也就是说，这些次数很少，因为我倾向于避免这样做的代码……这对我来说是一种代码的味道。|120239|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

For my programming, I tend to only test that parts of the code that I can't intuitively look at and know it's going to work (which some people will argue isn't enough, but that's neither here nor there). 

I've been programming that way a long time, and that I use those tests to help me write my code in the first place. Given that, the time to write my tests add, basically, nothing to my overall development time. If I skipped writing the tests I do, it "might" save me 10% of my time overall, if that.

When I first started using automated testing, I'd say a doubling over the overall time to write code is a fair estimate. But, over time, I've gotten to where I am not (adding next to no time). Honestly, it's something you get used to and it becomes part of how you design your code in the first place.

Edit: It occurs to me to add that there are times when writing the test code still adds a fair amount of time to my coding, sometimes well more than double. That being said, those times are few and far between as I tend to avoid code that does so... it's a code smell to me.

blocks|key|1525645|text|如果你对单元测试是认真的，我推荐Roy+Osherove写的The+art+of+unit+testing这本书。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1525646|entityMap|0|LINK|mutability|MUTABLE|url|http://weblogs.asp.net/rosherove/|1|http://www.artofunittesting.com/^0|G|C|0|U|N|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

If youre serious about unit testing I would recommend the book <a href="http://www.artofunittesting.com/" rel="nofollow noreferrer">The art of unit testing</a> by <a href="http://weblogs.asp.net/rosherove/" rel="nofollow noreferrer">Roy Osherove</a>.

blocks|key|326045|text|为应用程序编写(编码)+|type|unstyled|depth|inlineStyleRanges|entityRanges|data|326046|单元测试可以有效地将项目所需的开发时间提高一倍。|blockquote|326047|326048|326049|如果你只计算输入代码的时间，那么写测试肯定比不写测试要慢。然而，如果你在没有测试安全网的情况下考虑到破坏现有功能-调试-修复的时间因素，那么除了琐碎的项目之外，收益通常会超过任何成本。测试通过设计(TDD)+%2B防御(回归)%2B文档(规范)为您提供帮助。|326050|326051|这是真的吗，尤其是对于初学者？|326052|326053|326054|那得看情况。套用Beck的话(我想)，如果你是个笨蛋，工具/冰毒不会对你有帮助，如果你是个编程之神，你可能不需要它们。然而，对于我们中间的大多数人来说，这是有帮助的。当你朝着那个光谱的右边移动时，事情变成了你的第二天性，你将“看到”即将到来的事情，所花费的时间开始减少(尽管不是0)。为了避免犯新手错误，找一个已经在那里工作过的人(从邮件列表中寻求帮助，或者暂时雇佣一个好教练)|326055|326056|还提出了一些后续问题(布朗尼要点)：如果您正在做一个客户项目，并在完成后移交，那么是否值得花费时间和精力进行单元测试？|326057|326058|326059|即使下一个团队放弃了测试套件，我仍然会这样做，以保持我的生产力，并减少花在创建和跟踪bug上的时间。|326060|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|D|7|14|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|17|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|19|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1C|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|X|$]]

<blockquote>
 writing (coding) unit tests for your
 application effectively doubles the
 development time required for
 projects. 
</blockquote>

Writing tests is definitely slower than writing no tests at all if you just count the time typing out code. However if you factor in time for breaking existing functionality-debugging-fixing without the safety net of tests, the benefits will generally outweigh the costs for anything other than trivial projects. Tests aid you with Design (TDD) + Defense (Regression) + Documentation (Specs). 

<blockquote>
 Is this true, particularly
 for beginners?
</blockquote>

It depends. To paraphrase Beck (I think), if you're a dunce, tools/meth won't help you, if you're a coding-God, you probably don't need them. However for most of us in the middle, it helps. As you move towards the right on that spectrum, things become second nature to you, you being to 'see' whats coming and time-taken begins to reduce (although not to 0). To avoid making rookie mistakes, find someone who's already been there (get help from a mailing list or hire a good coach for a while) 

<blockquote>
 Also some follow-up questions (brownie points): If you were doing a client project that 
 you hand off when finished, is it worth the time and effort to do unit testing?
</blockquote>

Even if the next team chucked the test suite, I'd still do it to keep my productivity up and reduce time spent creating and chasing bugs.

blocks|key|120350|text|如果您使用的是TDD，则不会，因为：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|120351|，|120352|，你实际上是先写测试。这本身就节省了大量的时间，因为你已经准备好了你要做的事情。您还可以确切地知道何时停止编码。(当测试通过时)|unordered-list-item|120353|当你实际编写代码时，它会尽可能地小。您可以在通过测试时停止编码，然后只要测试仍在通过，您就可以信心十足地使其变得更好。|120354|然后为边缘情况编写测试(如果有必要)，并检查是否会出现问题。|120355|120356|我这样做了，发现这实际上减少了开发时间-因为你甚至在开始编写实际代码之前就已经考虑到了你想要做什么，并且你知道当你完成它时，它实际上是有效的。|120357|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|F|7|R|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|T|8|@]|9|@]|A|$]]|$1|K|3|-4|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|$]]

Not if you're using TDD because:

<ul>
<li>You actually write your test first. This is itself is a big time saver, since you've laid what you're setting out to do. You also know exactly when to stop coding. (When the test passes)</li>
<li>When you actually write the code, it winds up being as small as possible. You can stop coding when you pass the test, and you can then make it better confidently as long as the test is still passing. </li>
<li>Then write tests for the edge cases (if necessary) and check the would be problems. </li>
</ul>

I've done this and found this actually cuts down dev time - because you're already thought about what you want to do before you even start writing the actual code, and you know when when you've done it that it actually works.

blocks|key|326114|text|这取决于你所获得的好处。对于传统的web应用程序来说，这完全是浪费时间--客户将更多地抱怨混乱的ui，而不是缓慢地破坏数据的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|326115|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Depends on benefit you are getting. It is a complete waste of time for conventional web apps - clients will bitch more about messed up ui, rather than code slowly corrupting data.

I have heard that writing (coding) unit tests for your application effectively doubles the development time required for projects. Is this true, particularly for beginners?

Also some follow-up questions (brownie points):
If you were doing a client project that you hand off when finished, is it worth the time and effort to do unit testing?

Unit Testing - how much more time does it really add?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我听说为应用程序编写(编码)单元测试可以有效地将项目所需的开发时间提高一倍。这是真的吗，尤其是对于初学者？还有一些后续问题(布朗尼要点)：如果你正在做一个客户项目，并在完成后移交，那么是否值得花费时间和精力进行单元测试？

问单元测试--它实际上增加了多少时间？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单元测试--它实际上增加了多少时间？EN