单元测试适用于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应用程序用户交互等)，但即使如此，我们在这个商店里都被测试感染了，当我们把测试束缚住时，我们最高兴。我怎么极力推荐这种方法都不为过。

使用单元测试套件，可以在保持其余功能不变的情况下对代码进行更改。这是一个很大的优势。当你完成新功能的编码时，你会使用单元测试套件和回归测试套件吗?