我继承了一个没有单元测试的遗留Web应用程序。我想添加一些单元测试,但不知道从哪里开始。我应该在旧代码中添加它们吗?还是只在以后的新代码中添加?如果该代码与遗留代码交互怎么办?你有什么建议?
我继承了一个没有单元测试的遗留Web应用程序。我想添加一些单元测试,但不知道从哪里开始。我应该在旧代码中添加它们吗?还是只在以后的新代码中添加?如果该代码与遗留代码交互怎么办?你有什么建议?
这个传统应用程序是分层的吗?
如果是分层的,首先在后端/业务层添加单元测试
如果不是分层的,则在新代码上前进时添加单元测试,并在发现错误时进行回归测试
如果您有时间/雄心,想要逐步完成整个单元测试,请先列出功能列表(优先考虑关键功能),然后一次添加几个单元测试。
如果你继承的是代码,那么你需要开始阅读并理解它的功能和不足之处。我建议你编写单元测试来反映你对代码库的逐渐理解。最终,你将建立起一个有关遗留应用程序的知识体系,其中包括“这些函数是通过这些测试的函数”而不是“这些函数是具有这些实现的函数”。然后你就可以更自由、更有信心地进行更改,而不会破坏原有的功能。
在应用程序的已知“痛点”编写测试。经常出错或风险较高的代码是一个好的起点,因为它有助于在这个领域建立第一道防线,并让团队了解该应用程序中单元测试的范围。
每次针对应用程序开放缺陷时,尝试编写单元测试以暴露此行为。这将让您知道何时修复它,并希望防止将来再次引入它。
此外,寻找需要重构的代码。任何重构工作都应以创建单元测试为前提。这有助于确保在您进行更改之前和之后都可以正常工作。重构可能在开始时很困难,因为存在“连锁反应”的风险,其中一个故障可能会以意想不到的方式在整个应用程序中造成严重影响。