C# 在开始一项新工作之前，你会考虑系统的“单元可测试性”吗？

我找到了一份新的工作，开始了一个让我再次认识到单元测试重要性的系统；我指的是适当的单元测试，不需要个人点击按钮与测试交互，甚至不需要点击数据库或WCF，也不需要跨越其上下文中的任何其他架构边界。您应该能够在任何地方、任何时间、任意次数地运行这些测试

但是这个系统是巨大的，它有大约700个项目，分布在300多个解决方案文件中。该系统直接引用“程序文件”中部署位置的DLL，在许多地方都可以找到“循环引用”。在开发人员更改代码库中的某些内容后，他们将手动将DLL复制到各个位置或通过电子邮件相互发送。有些控制器有21000行21K代码。它可以是一个“大泥球”

我向他们展示了如何以及在何处为系统添加一两条不会影响任何人的接缝，这样我们就可以开始对系统进行单元测试，因为他们似乎同意他们需要这个安全网，并且他们注意到整个行业都在谈论它的好处。但现在，当“在类上公开某些内容的新属性”破坏了他们的构建时，我开始受到团队中其他架构师的抵制

这就是变化。公开现有私有字段的新属性

public INavigationComponent CurrentNavigationComponent { get { return _currentNavigationComponent; } }

一位架构师和他的一位开发人员没有耐心也不知道如何弄清楚他们在哪里有一个旧的dll，所以他们要求我删除这个属性，我做到了，但他仍然无法构建

因此，如果团队不愿意在类中添加一个属性来支持另一个级别的测试，那么我感觉就像是在向墙布道

对于新的工作环境来说，单元可测试系统是过于严格还是过于乐观

---

我猜人们会回答“向您的团队推销单元测试的概念和好处是我/您的工作，如果您做不到，那么……”。

欢迎来到现实世界

根据我的经验，综合单元测试通常会将开发时间增加约5倍；从长远来看，它能节省多少时间，还没有定论。如果你在一个以质量控制为重的行业工作，你会立刻想到航空和医药这两个行业，那么这是不需要动脑筋的，但对于大多数行业来说，还有许多其他因素在起作用，包括上市时间问题、现金流、营销要求、，竞争的力量和其他很多与实际编程无关的东西

正确看待事物是很重要的。作为一名新员工，你的工作不是告诉他们如何开发他们的系统。你能做的最好的事情就是证明你会为了公司的利益与你的团队和其他部门合作，即使这意味着必须做出妥协。别误会我的意思，你有责任向上级传达你对项目的担忧，尤其是当你认为这些担忧可能会产生长期影响时。但是，你的工作也是接受做出的任何决定，即使这些决定与你背道而驰，并且尽你所能做好你的工作

---

一句话：做一个好的程序员只是做一个好程序员的一小部分。

这个问题主要是基于观点的，没有对错之分。我要说的是，如果你觉得自己已经尝试过了，但无法让人们看到好处，并且你不喜欢事情的现状，那么也许这个工作场所不适合你。听起来像是地狱般的建筑体系。@YuvalItzchakov，我不同意你的第一句话。开发软件有正确的方法和错误的方法。编写可测试代码是正确的方法。不过，我同意你的建议：如果组织中的其他人不愿意听取关于如何改进事情的建议，OP可以选择离开或将其归为一类。@DavidArno这并不是绝对真理。我知道一些系统不使用任何单元测试，但是有很好的QA，并且工作得非常好。根据开发组和产品的特点，它确实有所不同。这也显示了OP为什么这个问题不适合这么做。@YuvalItzchakov，是的，构建系统是一个相当大的挑战，在过去的几个月里它有了相当大的改进。我们的开发团队中的人员现在复制dll的次数大大减少，并使用改进的构建实用程序来决定何时部署dll。我们还将构建时间从6.5分钟缩短到10到2分钟，这取决于哪个项目被更改。这是一个很好的答案。我也同意，并不是所有的行业都从一开始就需要它。具有讽刺意味的是，在我看来，这一次确实如此。团队中的一位高级架构师同意我建议的只是一处房产的变更，但他也暗示我需要提高我的软技能，以及 试着让反对改变的人站在我这边，站在我这边。但是鹅，回到最初的问题，这将是一个很好的方法来避免进入一个有这么多砖墙的系统。