我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。


当前回答

One of the best things about unit testing is that your code will become easier to test as you do it. Preexisting code created without tests is always a challenge because since they weren't meant to be unit-tested, it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class - like an e-mail sending service reference - and so on. But don't let this bring you down! You'll see that your overall code design will become better as you start to write unit-tests, and the more you test, the more confident you'll become on making even more changes to it without fear of breaking you application or introducing bugs.

There are several reasons to unit-test your code, but as time progresses, you'll find out that the time you save on testing is one of the best reasons to do it. In a system I've just delivered, I insisted on doing automated unit-testing in spite of the claims that I'd spend way more time doing the tests than I would by testing the system manually. With all my unit tests done, I run more than 400 test cases in less than 10 minutes, and every time I had to do a small change in the code, all it took me to be sure the code was still working without bugs was ten minutes. Can you imagine the time one would spend to run those 400+ test cases by hand?

当涉及到自动化测试——无论是单元测试还是验收测试——每个人都认为编写可以手动完成的代码是浪费精力,有时这是真的——如果你计划只运行一次测试的话。自动化测试最好的部分是,您可以毫不费力地运行它们几次,并且在第二次或第三次运行之后,您所浪费的时间和精力已经得到了补偿。

最后一个建议是,不仅要对代码进行单元测试,还要先进行测试(详见TDD和BDD)。

其他回答

你应该尽量少测试!

这意味着,您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改,并且必须更改测试,那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。

我经常看到许多永远不会崩溃的测试,它们又大又笨拙,没有提供太多价值,它们最终只会拖慢你的速度。

简而言之——是的。它们值得你付出每一分努力……在某种程度上。在一天结束的时候,测试仍然是代码,并且很像典型的代码增长,您的测试最终将需要重构,以便可维护和可持续。有一大堆的陷阱!当涉及到单元测试时,但是没有什么,我的意思是没有什么比丰富的单元测试集更能让开发人员更自信地进行更改了。

I'm working on a project right now.... it's somewhat TDD, and we have the majority of our business rules encapuslated as tests... we have about 500 or so unit tests right now. This past iteration I had to revamp our datasource and how our desktop application interfaces with that datasource. Took me a couple days, the whole time I just kept running unit tests to see what I broke and fixed it. Make a change; Build and run your tests; fix what you broke. Wash, Rinse, Repeat as necessary. What would have traditionally taken days of QA and boat loads of stress was instead a short and enjoyable experience.

提前准备,一点点额外的努力,当你不得不开始摆弄核心特性/功能时,它会给你带来十倍的回报。

我买了这本书——它是xUnit测试知识的圣经——它可能是我书架上被引用最多的书之一,我每天都在查阅它:链接文本

我在几年前发现了TDD,从那时起我就使用它编写了所有我喜欢的项目。我估计,TDD一个项目所花费的时间与牛仔式地组合一个项目所花费的时间大致相同,但我对最终产品的信心增加了,以至于我忍不住有一种成就感。

我还觉得它改进了我的设计风格(更面向界面,以防我需要一起模拟东西),而且,正如顶部的绿色帖子所写的,它有助于“编码便秘”:当你不知道接下来要写什么,或者你有一个令人生畏的任务摆在你面前时,你可以写小一点的。

最后,我发现到目前为止,TDD最有用的应用是在调试中,如果仅仅因为您已经开发了一个询问框架,那么您就可以用它来刺激项目以可重复的方式产生错误。

我是一名维护工程师,负责一个文档记录不佳、糟糕而庞大的代码库。我希望编写代码的人已经为它编写了单元测试。 每次我进行更改和更新产品代码时,我都担心自己可能会因为没有考虑某些条件而引入错误。 如果他们编写测试,那么对代码库的更改就会更容易、更快。(与此同时,代码库将处于更好的状态)..

我认为,在编写api或框架时,单元测试非常有用,因为这些api或框架必须持续多年,并由原始编码器以外的人使用/修改/发展。

One of the best things about unit testing is that your code will become easier to test as you do it. Preexisting code created without tests is always a challenge because since they weren't meant to be unit-tested, it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class - like an e-mail sending service reference - and so on. But don't let this bring you down! You'll see that your overall code design will become better as you start to write unit-tests, and the more you test, the more confident you'll become on making even more changes to it without fear of breaking you application or introducing bugs.

There are several reasons to unit-test your code, but as time progresses, you'll find out that the time you save on testing is one of the best reasons to do it. In a system I've just delivered, I insisted on doing automated unit-testing in spite of the claims that I'd spend way more time doing the tests than I would by testing the system manually. With all my unit tests done, I run more than 400 test cases in less than 10 minutes, and every time I had to do a small change in the code, all it took me to be sure the code was still working without bugs was ten minutes. Can you imagine the time one would spend to run those 400+ test cases by hand?

当涉及到自动化测试——无论是单元测试还是验收测试——每个人都认为编写可以手动完成的代码是浪费精力,有时这是真的——如果你计划只运行一次测试的话。自动化测试最好的部分是,您可以毫不费力地运行它们几次,并且在第二次或第三次运行之后,您所浪费的时间和精力已经得到了补偿。

最后一个建议是,不仅要对代码进行单元测试,还要先进行测试(详见TDD和BDD)。