我的团队的一个持续关键点是我们的“共同”图书馆。 （在这里查看相关问题，说“框架”可能更为正确。）
目前包含v1，v2和v3。其中v3用于所有新应用程序。它包含多个WCF服务，一个包含业务对象的类库，以及一个用于js / css / images的公共Web目录。
我们希望在我们前进的过程中做正确的事情，特别是因为我们都积极开始为共同图书馆做出贡献。它变成了一个巨大的泥球，并且部署它对每个人来说都是可怕的。
我们首先想到的是设置一个测试服务器，在所有代码中运行单元测试，以确保没有任何中断。问题是为所有内容编写测试非常繁琐，坦率地说，没有人有这样的时间。我们对编写适当的单元测试也缺乏经验。话虽如此，如果这是最好的路线，我们会完成它。
在那之后，我们不太确定。我们将公共代码视为应用持续集成实践的地方，因为我们编写了许多使用它的不同应用程序。
这也引入了一些问题，例如将DLL复制到本地，或者将某些内容放在某个服务器上。我们已经感觉像是在DLL地狱，想要离开。
（好）软件商店用于管理此类情况的策略是什么？
感谢任何建议。如果需要更多信息，请询问。我很乐意提供它。
谢谢！
答案 0 :(得分：8)
问题在于为所有内容编写测试非常繁琐，坦率地说，没有人有这样的时间
真正的问题是你编写的代码没有TDD方法（测试应该先编写），现在在一个以测试为重点的项目中（它应该在每个项目中发生），测试通常需要更多时间或相同写这篇真实代码的时间。为什么？因为当您编写测试时遵循TDD时，您实际上是在设计代码，并且您遵循此模式的红绿重构
你绝对应该开始为你的代码编写测试，现在的问题（我敢于采取这种假设）是你和你的团队没有编写可测试代码。
检查此帖子https://stackoverflow.com/a/10365073/1268570
假设并非所有代码都是可测试的，那么创建单元测试将是一个真正的痛苦，你可以编写某种集成测试。
关于CI服务器，你应该去实现它，实际上CI不应该是每个严肃项目的可选项
我实际上正在创建一个工具来简化与CI服务器的集成，它包含一组MSBuild脚本，包含第三方工具来执行每个项目应该遵循的常见任务，我还没有发布但是我还没写完文档，但它现在可以使用，你可以看看：
https://github.com/jupaol/NCastor/tree/develop
检查开发分支，因为在我发布新版本
之前我不会合并为master关于版本控制，如你所说，留下“dll hell”，这让我觉得你没有版本控制标准，我建议你检查语义版本控制模型：
BTW我发现在组织内部分发新组件版本的一个好策略是设置一个私有Nuget服务器，并发布到该组件的Nuget软件包。当然，要实现这一点，您需要将组件打包为Nugets，但这很容易实现。
以本文为参考，全力以赴：
使用TDD方法编写单元测试
编写干净的可测试代码
实施CI服务器
http://misko.hevery.com/2008/07/16/top-10-things-i-do-on-every-project/
我建议你在编写测试时使用的工具：
答案 1 :(得分：4)
为自己准备2本书并让它们阅读。
第一本书将教您使用遗留代码和重构模式的最佳实践，以及如何围绕代码进行有意义的单元测试。
第二本书是经验丰富的单元测试仪和新手单元测试仪的优秀资源。
最后永远不要让借口/理由“一切都非常乏味，坦白说没有人有这样的时间。”阻止你接受良好的做法。一个好的有意义的单元测试总比没有好。
使其成为一个标准，没有“新”代码写入单元测试以支持它。并将代码评审作为您日常工作的一部分。
祝你好运，玩得开心。
答案 2 :(得分：4)
坦率地说，没有人有这样的时间。
...但你有充足的时间来纠正事后“它”造成的问题吗？
如果有的话，为消费“常见”的应用创建冒烟测试，这些应用将贯穿核心功能，以确保它们在新的通用版本之后仍能正常工作。
之后，查看一些代码覆盖工具，了解您未测试的内容。然后，作为一个团队，您可以添加逐渐构建覆盖范围的项目。
＆LT;肥皂盒＆GT;
你应该编写单元测试，特别是对于“常见”代码，因为代码可能会以一种开发人员的意愿改变，而开发人员以稍微不同的方式使用它。
＆LT; /肥皂盒＆GT;