5

我刚刚阅读了这篇文章，它提出了在开始使用测试驱动开发/设计时使用隐式类型的理由。

他的帖子说，在对方法进行单元测试时使用隐式类型作为返回类型时，TDD 可能会“减慢”速度。此外，他似乎想要测试指定的返回类型以推动开发（这对我来说很有意义）。

具有隐式类型的给定单元测试可能如下所示：

public void Test_SomeMethod()
{
    MyClass myClass = new MyClass();

    var result = myClass.MethodUnderTest();
    Assert.AreEqual(someCondition, result);
}

所以我的问题是：

使用隐式类型是帮助还是阻碍为 TDD 编写单元测试？有没有人可以分享他们在编写单元测试时使用这种技术的经验？

我问这个是因为很快我还没有完成 TDD，并且想知道是否有办法编写通用或半通用单元测试，返回类型可能会改变。

4

3 回答 3

3

我明白他的观点，但我真的不认为这是不在var这里使用的正确理由。请记住，TDD 的工作原理大致如下：

  1. 写一个新的测试。
  2. 如果测试无法编译（它应该会失败！），编写足够的代码直到测试编译。
  3. 运行所有测试。
  4. 如果测试失败，请编写足够的代码，直到所有测试都通过。
  5. 重构。

无论我们是否使用var测试都将无法编译，因为被测试的方法还不存在！一旦我们开始编码，NewMethod他的观点就没有实际意义了。

相反，不在var这里使用的正确原因是因为代码没有说明类型result是什么。这是一个见仁见智的问题，但var在这里可以

var dict = new Dictionary<Foo, List<Bar>>();

对于匿名类型，但不在这里

var m = M();

因为如果不去声明M（或使用 IntelliSense）返回类型M是什么，则完全不清楚。

于 2010-01-26T16:24:48.487 回答
1

是和否

目前在 Visual Studio 中，TDD 有点痛苦，尤其是在使用隐式类型时。var意味着没有智能感知，那么当您输入可能不存在的类型的名称时，它倾向于自动完成与您输入的内容相似的内容，通常是测试夹具的名称。

Visual Studio 2010 具有使用优先模式，这使其成为测试驱动开发的理想选择。目前你会发现（在 2008 年及更早的版本）你必须点击escape才能隐藏智能感知。

至于使用var它是纯粹的突触糖。在我看来，它使以下内容变得更好：

var type = new MyType();

很明显，变量类型是 MyType 类型。var非常适合泛型并遵循 DRY - Don't Repeat Yourself的原则。

var type = MethodCall();

var result = ReturnResult();

另一方面，这使得代码难以阅读，无论您是否遵循 TDD。好的单元测试应该流畅且易于阅读。如果你必须思考，或者将鼠标悬停在一个方法上才能看到返回类型，那是一个糟糕的、难以阅读的测试的标志。

于 2010-01-26T16:31:46.103 回答
0

从工具的角度来看，我会说避免使用 var 会更好。我使用 Eclipse 和 Java，但我知道像 CodeRush 和 Resharper 这样的扩展提供了我在这里讨论的许多特性。当我在测试中调用一个尚不存在的方法时，我可以“快速修复”它以在所需的类中创建该方法。自动创建的方法的返回类型取决于它的上下文；如果我期待返回一个字符串，则该方法的返回类型将是字符串。但是，如果分配给一个 var（Java 没有 - 但如果有），IDE 将不知道将返回类型设置为 var（或者可能是 Object）以外的任何类型。

不是每个人都以这种方式在 TDD 中使用 IDE，但我发现它很有帮助。我可以在测试中为 IDE 提供的信息越多，我为使测试通过所需的输入就越少。

于 2010-01-26T21:43:30.210 回答