当您无法更改其他文件时,打破依赖关系?

时间:2010-05-11 18:45:58

标签: unit-testing dependencies break

我正在为一个项目做一些隐形敏捷开发。首席程序员将单元测试,重构等视为浪费资源,否则无法说服他。他的哲学是“如果没有破坏就不要修理它”,我理解他的观点。他已经在这个项目上工作了十多年,并且知道里面和外面的代码。我不打算讨论开发实践。

我是该项目的新手,我的任务是添加一项新功能。我之前曾在遗留项目上工作并使用敏捷开发实践,结果很好,但这些团队更容易接受这个想法,并且不怕改变代码。

我被告知我可以使用我想要的任何开发方法,但我必须将我的更改限制为仅添加该功能所需的更改。我正在使用tdd来处理我正在编写的新类,但是我一直在遇到由于全局变量的自由使用和我需要与之交互的类中的高耦合而导致的路障。通常我会开始为这些类提取接口,并通过将它们作为构造函数参数或公共属性注入来明确地依赖全局变量。

我可以说这些变化是必要的,但考虑到领导从来没有做过,我怀疑他会看到我的方式。我可以使用哪些技术来打破这些依赖关系而不会引起主要开发人员的注意?

我已经取得了一些进展:

  • 提取界面(对于我正在创建的新类)
  • 使用测试存根扩展和覆盖任意类。 (幸运的是,大多数方法都是公共虚拟的)

但这两个只能让我到目前为止。

注意

负责人的部分职责是审核代码提交。他可能会将反腐败层理解为充其量过多,最糟糕的是侮辱。

2 个答案:

答案 0 :(得分:0)

您应该创建一个反腐败层,在这里您基本上使用包装类在您和“expert”代码之间保留一层。这将是处理这种废话的代价。

还有一些模拟框架允许您处理不必更改现有代码,但这些可能会让您在政治上比简单的包装类更麻烦。

答案 1 :(得分:0)

在这种情况下,反腐败层可能有效,但你必须要小心,因为太多这些都会导致相当可怕的结果。

使用这样的图层,您可能会威胁到系统的其余部分,就像威胁外部资源一样。