我正在努力将单元测试集成到我工作的团队的开发过程中,并且有一些怀疑论者.有什么好的方法可以让团队中持怀疑态度的开发人员相信单元测试的价值？在我的具体情况下,我们将添加单元测试,因为我们添加功能或修复了错误.不幸的是,我们的代码库不适合简单的测试.
任何人都可以推荐一些关于如何解决启动UnitTest大型现有CodeBase问题的最佳实践吗？我目前面临的问题包括:
显然,我明白我应该从重构代码开始,使它更少耦合,更可测试.但是,如果没有UnitTests(鸡和鸡蛋,任何人？),进行这样的重构是有风险的.
另外,您是否建议在Domain类或层级类(日志记录,实用程序等)上启动重构和编写测试？
我是一名嵌入开发团队的软件测试工程师.我工作的很大一部分涉及检查项目的自动化测试状态(主要是单元/集成测试).
我不是一个想要强迫测试每个人的喉咙的短视狂热者,但我确实希望帮助每个人在他们花在编写测试上的时间里获得最大的收益.每周花大量时间编写测试,因此最大化回报非常重要.
现在,我做了一些尝试和帮助的事情.首先,我总是让自己谈论可测性问题.例如,尝试识别测试策略,特定设计是否可测试等等.
除了向人们解释事情并且通常试图帮助他们之外,我还会审查完成的代码和他们编写的测试(我必须签署故事,这意味着我也有点对抗).
我目前的流程是单独坐下来,通过他们的代码,书签和评论所有问题区域,可以改进的地方以及原因.然后,我将开发人员带到我的电脑上,并通过所有评论点进行讨论.然后我给他们一个体面的写作,所以他们有一个记录,他们很容易参考.
我不修复他们的代码和测试,但如果我发现差距,我会添加更多测试用例等.我之所以决定不对它们进行测试的原因是开发人员太容易说"谢谢"而是要退出.我的理由是,如果他们必须在我签署之前解决我发现的问题,这将导致更好的项目测试标准(即更自给自足的开发人员测试).
我的问题是:在帮助团队时,我能做得更好吗？您发现哪些方法有益？
我特别希望听到那些担任类似职位的人面临同样的挑战(例如,帮助提高测试质量,证明价值测试可以带来相关的情况,并在支持和对抗之间取得良好的平衡.)
*编辑:感谢您的回答; 所有这些都包含有用的建议.我认为最好的答案是最好的答案,因为我认为它归结为开发人员的支持,并且配对编程是我尚未尝试过的(缺少一些即兴的'这里是我如何做这个'示范在测试之后书面).我会和任何努力测试的人一起去试试:)干杯.