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


当前回答

Yes - Unit Testing is definitely worth the effort but you should know it's not a silver bullet. Unit Testing is work and you will have to work to keep the test updated and relevant as code changes but the value offered is worth the effort you have to put in. The ability to refactor with impunity is a huge benefit as you can always validate functionality by running your tests after any change code. The trick is to not get too hung up on exactly the unit-of-work you're testing or how you are scaffolding test requirements and when a unit-test is really a functional test, etc. People will argue about this stuff for hours on end and the reality is that any testing you do as your write code is better than not doing it. The other axiom is about quality and not quantity - I have seen code-bases with 1000's of test that are essentially meaningless as the rest don't really test anything useful or anything domain specific like business rules, etc of the particular domain. I've also seen codebases with 30% code coverage but the tests were relevant, meaningful and really awesome as they tested the core functionality of the code it was written for and expressed how the code should be used.

在探索新的框架或代码库时,我最喜欢的一个技巧是为“它”编写单元测试,以发现事物是如何工作的。这是一个学习新事物的好方法,而不是阅读枯燥的文档:)

其他回答

你想说服谁?工程师还是经理?如果你试图说服你的工程师同事,我认为你最好的办法是迎合他们的愿望,让他们做出高质量的软件。有许多研究表明,它能发现漏洞,如果他们关心做好工作,这对他们来说就足够了。

如果您试图说服管理层,您将很可能不得不做一些成本/收益推理,说明未检测到的缺陷的成本大于编写测试的成本。一定要把不可转化的成本也包括在内,比如失去客户的信心等等。

单元测试适用于QA人员或你的经理,而不是你;所以绝对不值得。

您应该专注于编写正确的代码(不管这意味着什么),而不是测试用例。让其他人去担心吧。

在我们的办公室里,每天都有这样的对话:

“伙计,我就是喜欢单元测试,我刚刚能够对某些东西的工作方式进行了一系列更改,然后能够通过再次运行测试来确认我没有破坏任何东西……”

细节每天都在变化,但情绪却不变。单元测试和测试驱动开发(TDD)有很多隐藏的和个人的好处,也有很多明显的好处,除非他们自己做,否则你无法真正向他们解释。

但是,忽略这一点,下面是我的尝试!

Unit Tests allows you to make big changes to code quickly. You know it works now because you've run the tests, when you make the changes you need to make, you need to get the tests working again. This saves hours. TDD helps you to realise when to stop coding. Your tests give you confidence that you've done enough for now and can stop tweaking and move on to the next thing. The tests and the code work together to achieve better code. Your code could be bad / buggy. Your TEST could be bad / buggy. In TDD you are banking on the chances of both being bad / buggy being low. Often it's the test that needs fixing but that's still a good outcome. TDD helps with coding constipation. When faced with a large and daunting piece of work ahead writing the tests will get you moving quickly. Unit Tests help you really understand the design of the code you are working on. Instead of writing code to do something, you are starting by outlining all the conditions you are subjecting the code to and what outputs you'd expect from that. Unit Tests give you instant visual feedback, we all like the feeling of all those green lights when we've done. It's very satisfying. It's also much easier to pick up where you left off after an interruption because you can see where you got to - that next red light that needs fixing. Contrary to popular belief unit testing does not mean writing twice as much code, or coding slower. It's faster and more robust than coding without tests once you've got the hang of it. Test code itself is usually relatively trivial and doesn't add a big overhead to what you're doing. This is one you'll only believe when you're doing it :) I think it was Fowler who said: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all". I interpret this as giving me permission to write tests where I think they'll be most useful even if the rest of my code coverage is woefully incomplete. Good unit tests can help document and define what something is supposed to do Unit tests help with code re-use. Migrate both your code and your tests to your new project. Tweak the code till the tests run again.

我参与的很多工作都没有很好地进行单元测试(web应用程序用户交互等),但即使如此,我们在这个商店里都被测试感染了,当我们把测试束缚住时,我们最高兴。我怎么极力推荐这种方法都不为过。

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

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

Unit testing helps a lot in projects that are larger than any one developer can hold in their head. They allow you to run the unit test suite before checkin and discover if you broke something. This cuts down a lot on instances of having to sit and twiddle your thumbs while waiting for someone else to fix a bug they checked in, or going to the hassle of reverting their change so you can get some work done. It's also immensely valuable in refactoring, so you can be sure that the refactored code passes all the tests that the original code did.