我的任务是为公司制定内部测试标准和程序的文件。我一直在做大量的研究，发现了一些很好的文章，但我总是想在这里与社区联系以获取意见。
话虽如此，我的问题是这样的：你如何选择一个拥有非常庞大的遗留代码库的公司，如果完全可测试的话，几乎无法测试，并尝试有效地测试你的内容？您是否有关于如何为紧密耦合的代码创建一些有用的自动化测试用例的任何提示？
我们所有的新代码都被编写为尽可能松散耦合，我们都为新开发的方向感到自豪。为了记录，我们是一家从VB转向C＃ASP.NET开发的微软商店。
答案 0 :(得分：0)
这个问题实际上有两个方面：技术和政治。
技术方法在Michael Feathers的书Working Effectively With Legacy Code中有很好的定义。既然你无法一次性测试整个代码块，那么就可以将它与想象中的非架构“接缝”分开。这些将是代码中的逻辑阻塞点，其中功能块似乎与代码库的其余部分有些隔离。这不一定是拆分它的“最佳”架构场所，而是选择一个可以自行测试的隔离逻辑块。此时将其拆分为两个模块：大部分代码和隔离的函数。现在，在此时添加自动化测试以执行隔离的功能。这将证明您对逻辑所做的任何更改都不会对大量代码产生负面影响。
现在你可以按照SOLID OO设计原则，DRY原则等去镇上并重构孤立的逻辑。Martin Fowler's Refactoring本书在这里是一个很好的参考。在重构时，将单元测试添加到新重构的类和方法中。尽量保持你所创造的分裂的“背后线”;这有助于防止兼容性问题。
您最终想要的是一套结构良好的完全单元测试逻辑，遵循最佳OO设计;这将附加到临时兼容层，该层将其连接到您之前剪切的接缝。对其他孤立的逻辑部分重复此过程。然后，您应该能够开始加入它们，并丢弃临时图层。最后，你最终会得到一个漂亮的代码库。
提前注意，这需要很长时间。从而进入政治。即使您说服您的经理改进代码库将使您能够更好/更便宜/更快地进行更改，但这种观点可能不会由他们之上的高管共享。高管们看到，重构代码所花费的时间不是花在添加所请求功能上的时间。而且他们没有错：你和我认为必要的维护不是他们想要花费有限预算的地方。在他们看来，今天的代码工作得很好，即使维护成本很高。换句话说，他们在想“如果没有破产，就不要修理它。”
您需要向他们展示一个计划，以获得重构的代码库。这将包括方法，涉及的步骤，您看到的大块工作以及估计的时间线。在这里提出替代方案也很好：完全重写会更好吗？你应该改变语言吗？您应该将其转移到面向服务的架构吗？您应该将其移入云端，并将其作为托管服务出售吗？所有这些都是他们应该在顶部考虑的问题，即使他们今天没有考虑它们。
如果您最终让他们同意，请浪费时间升级您的工具并建立一个现代化的开发链，其中包括同行代码审查和自动化单元测试执行，打包以及部署到QA等实践。
亲自吠叫这棵树11年了，我只能向你保证，这简直不容易。它需要在组织的技术阶梯顶部进行一直改变：CIO，CTO，开发高级副总裁或任何人。您还必须说服您的技术同行：您可能拥有与旧产品有着悠久历史且并不真正想要更改它的人。他们甚至可能会看到你抱怨他们目前的状态是对他们作为编码员的技能的个人攻击，并且可能会破坏你的努力。
我真诚地祝你好运，祝你好运！