java - 测试行为与实现

Question

我的任务是在没有测试的情况下对代码库进行小的更改，并且我第一次尝试使用 TDD 来实现更改，但我正在努力解决测试实现和行为之间的差异。我正在使用的系统呈现用户可配置的列表项。用户可以通过由 XML DAO 控制的全局偏好系统来更改列表项的行为:

class Preference {
  boolean getX();
  boolean getY();
}

我的任务是将 Z 添加到此 DAO，我已经实现了此更改并添加了测试以确保值按照我的预期进行序列化和反序列化。

下面的列表项类应该接收 Z 值:

class ListItemA extends ListItem {
  private boolean Z;

  ListItemA(boolean Z){
    this.Z = Z;
  }

  OpenAction getOpenAction(){
    OpenAction action = new OpenAction();

    if(Z){
       action.addValue('Filter', true);
    }

    return action;
  }
}

我还编写了测试以确保返回的操作反射(reflect) Z 字段。这两者之间的联系是我苦苦挣扎的地方，有一个 Controller 类在呈现列表项时被调用:

class Controller {
  private Preference preference;

  Controller(Preference preference){
    this.preference = preference;
  }

  List<ListItem> getListItems(State state){
    // a bunch condition statements concerning the state
    List<ListItem> items = new List();

    if(state.items.includes('ListItemA')){
      ListItemA item = new ListItemA();
    }

    return items;
  }

}

当实例化 ListItemA 时，我现在需要从首选项字段传递 getZ()，但 TDD 说如果没有首先失败的测试我就无法进行此更改。

我可以模拟首选项、模拟状态、生成列表，然后编写相同的测试以确保 OpenAction 反射(reflect) Z 的值，但这看起来好像我正在测试实现并编写一个脆弱的测试。此外，ListItem 测试中会有很多重复的测试代码，因为它们正在做出相同的断言。另一种选择是取消 ListItem 测试并在 Controller 测试中添加所有断言，但这似乎我正在测试另一个系统。

我的问题是:

• 如何在测试实现和编写过于宽泛的测试之间划清界线？

• 您将如何测试这种情况？

• 我是否过度测试了？

• 我正在通过 TDD 对这个遗留系统进行更改，根据我刚刚完成的“有效地使用遗留代码”一书，上述方法是否符合我在处理类似系统时应该进行的过程这？

• 是否有任何好的文章、书籍或资源可供我阅读以加深我对该领域的理解？

• 我如何在没有测试文化的工作场所测试遗留系统？我自己没有任何遗留系统可以使用，我如何获得经验？

Answer 1

How do I draw the line between testing implementation and writing tests that are too broad?

广泛的测试在跨越多个不稳定行为时往往最容易出问题 - 每当其中一个行为发生变化时，测试也会发生变化。这在单个编辑 session 中通常不是问题 - 因为即使是不稳定的行为也会在足够短的时间内趋于“稳定”。

如果您正在使用的遗留代码已捕获其更改历史记录(例如:源代码控制系统)，那么您可以查看代码的哪些部分是稳定的，并假设启发式“昨天的天气”会坚持。

I could mock the preference, mock the state,

您可以这样做，但这可能不是您的最佳起点。 Mocks 非常适合测试某些类型的设计——尤其是协议(protocol)——但你在测试协议(protocol)时获得的好处不一定会转移到其他样式。

如果测试对象对共享可变状态没有依赖，则有other techniques您可以使用它来生成更细粒度的测试，而无需引入模拟。

How do I go about testing a legacy system in a workplace with a no-testing culture?

在最坏的情况下？编写测试、实现更改、发布更改并放弃测试。将注意力集中在交付可以测试的高质量代码上，并将政治冲突推迟到以后。