您是否在专业项目中使用单元测试？

我们即将开始项目的一个新部分,似乎没有很多人对单元测试感兴趣(并且他们觉得他们没有经历过TDD).我相信它几乎是必不可少的,它使维护更容易.那你的看法是什么？

谢谢

顺便说一句:这是一个与语言无关的问题,但新项目是用Java编写的.

我发现单元测试不仅仅是一件有用的事情,它也是开发人员的责任.如果您发布未编写的代码以通过有效且全面的单元测试集,则可能会延迟您的项目,或导致其他人的包,类等问题.

此外,您应该与您的客户保持密切联系(即使它是您自己的公司),并尝试鼓励他们进行全面的验收测试.这符合他们的最佳利益(尽管我发现一些公司对这个想法有抵触,因为执行测试所需的短期时间,尽管如果产品没有完全确切地节省了大量的时间他们想要什么).

编辑

所以,是的,我想我想说的是:是的,我确实认为测试驱动开发是最佳选择.我当然没有提到的另一件事是测试有助于记录代码.您将知道这些方法应该做什么,并且当您在以后的任何阶段进行更改时,您将确保它们仍然可以执行.

绝对单元测试用于我们的项目.每个不是无脑的吸气剂和制定者的课程都经过单元测试.对代码进行功能测试使您可以随意重构,而不必担心您会同时破坏50个不同的东西.

单元测试的另一个被低估的方面是它将表面上的算法的忽略方面.我只花了两天时间使用正交数组编写和重写单元测试,因为每次我想出一个测试用例列表时,我发现了技术主管忽略了问题的另一个方面.

是.我们一直在使用TDD一段时间.不知何故,TDD已在我们身上发现,我们喜欢这种增量方法,以实现更好的代码质量.尽管有最初的否定曲线,您认为它会减慢开发过程中的一致性和渐进式单元测试,而编写代码在很多方面都是必不可少的.由于逐步建立的回归测试框架,编写重大变更非常困难.完成后,代码更加健壮,对代码和整个项目的信心也会受到积极影响.

如今写作单元测试不仅仅是精英.它应该是每个开发人员的责任.后来发现代码中的错误越多,修复成本就越高,找到它就越难.这很容易成为维护的噩梦.大力支持单元测试可以大大降低这种风险.

将单元测试和TDD的强大功能与配置良好的持续集成系统相结合,可以在项目的早期阶段快速发现问题.每日构建是避免未来和几乎肯定麻烦的必要条件.

单元测试需要付出代价.首先,您必须编写并验证所有额外代码.然后,您可能不得不在项目团队中推动昂贵的文化变革,以接受单元测试.

这个价格可能值得为您的特定项目支付.决定不应基于教条或轶事,而应基于对成本和收益的仔细分析.