相关疑难解决方法(0)

生产和测试代码常量之间的干燥

我通常会尽量避免重复并遵守DRY原则.但是,我想知道这样的情况:

public class Feature {
    final static String FEATURE_LABEL = "blah";

    public void doSomething() { ... }
    ...
}

public class FeatureTest {
    ...
    @Test
    public void doSomethingShouldMakeSomethingHappen() {
         assertEquals(Feature.FEATURE_LABEL, 
             feature.getSomethingHappens().getLabel());
    }
Run Code Online (Sandbox Code Playgroud)

如果要求标签是"blah"并且某人将FEATURE_LABEL更改为"bleh",则即使测试不再符合要求,测试也会通过.这是否是违反DRY的有效地方?

unit-testing constants dry

11
推荐指数
2
解决办法
1023
查看次数

硬编码的STRINGS是否可以接受?

类似于硬编码文字是否可以接受?,但我在这里特别想到"魔法字符串".

在一个大型项目中,我们有一个配置选项表,如下所示:

Name         Value
----         -----
FOO_ENABLED  Y
BAR_ENABLED  N
...
Run Code Online (Sandbox Code Playgroud)

(数以百计).

通常的做法是调用泛型函数来测试这样的选项:

if (config_options.value('FOO_ENABLED') == 'Y') ...
Run Code Online (Sandbox Code Playgroud)

(当然,可能需要在系统代码的许多地方检查相同的选项.)

添加新选项时,我正在考虑添加一个隐藏"魔术字符串"的函数,如下所示:

if (config_options.foo_enabled()) ...
Run Code Online (Sandbox Code Playgroud)

然而,同事们认为我已经过火了并反对这样做,更喜欢硬编码,因为:

  • 这就是我们通常做的事情
  • 它使得在调试代码时更容易看到发生了什么

麻烦的是,我可以看到他们的观点!实际上,我们永远不会出于任何原因重命名选项,因此我能为我的函数考虑的唯一优势是编译器会捕获像fo_enabled()这样的拼写错误,但不能捕获'FO_ENABLED'.

你怎么看?我错过了其他任何优点/缺点吗?

language-agnostic literals string-literals hard-coding

2
推荐指数
5
解决办法
5338
查看次数