“你好世界” - TDD 方式？

Question

自从我接触 TDD 以来，我一直在思考这个问题。 构建“Hello World”应用程序的最佳方法是什么？ 这将在控制台上打印“Hello World” - 使用测试驱动开发。

我的测试会是什么样子？ 以及大约什么班？

请求：没有指向什么是 TDD 的“类似于维基百科”的链接，我很熟悉 TDD。 只是好奇如何解决这个问题。

Answer 1

您需要将控制台隐藏在界面后面。 （无论如何，这可以被认为是有用的）

编写测试

[TestMethod]
public void HelloWorld_WritesHelloWorldToConsole()
{
  // Arrange
  IConsole consoleMock = MockRepository.CreateMock<IConsole>();

  // primitive injection of the console
  Program.Console = consoleMock;

  // Act
  Program.HelloWorld();

  // Assert
  consoleMock.AssertWasCalled(x => x.WriteLine("Hello World"));
}

编写程序

public static class Program
{
  public static IConsole Console { get; set; }

  // method that does the "logic"
  public static void HelloWorld()
  {
    Console.WriteLine("Hello World");
  }

  // setup real environment
  public static void Main()
  {
    Console = new RealConsoleImplementation();
    HelloWorld();
  }
}

重构为更有用的东西;-)

Answer 2

演示者视图？ （模型似乎并不是严格必要的）

View 是将输出传递到控制台的类（简单的单行方法）

Presenter 是调用 view.ShowText("Hello World") 的接口，您可以通过提供来测试它存根视图。

不过，为了提高生产力，我只需要编写该死的程序:)

一个测试就足够了（用伪代码）：

IView view = Stub<IView>();
Expect( view.ShowText("Hello World") );

Presenter p = new Presenter( view );
p.Show();

Assert.IsTrue( view.MethodsCalled );

Answer 3

嗯...我还没有见过 hello world 的 TDD 版本。 但是，要了解使用 TDD 和可管理性解决的类似简单问题，您可以查看 企业 FizzBu​​zz（代码）。 至少这会让您看到在 hello world 中可能实现的过度设计水平。

Answer 4

伪代码：

• 创建接受流的模拟。
• 通过某种依赖注入（如构造函数参数）将 helloworld 调用到此模拟中。
• 验证“Hello World”字符串是否已流式传输到您的模拟中。

在生产代码中，您使用提示而不是模拟。

经验法则：

• 定义组件如何与其他东西交互的成功标准，而不仅仅是它如何与你交互。 TDD 关注外部行为。
• 设置环境（模拟）来处理事件链。
• 运行。
• 核实。

Answer 5

一个非常有趣的问题。 我不是 TDD 的大用户，但我会提出一些想法。

我假设您要测试的应用程序是这样的：

public static void Main()
{
    Console.WriteLine("Hello World");
}

现在，由于我想不出任何直接测试它的好方法，所以我将把编写任务分解到一个接口中。

public interface IOutputWriter
{
    void WriteLine(string line);
}

public class ConsoleWriter : IOutputWriter
{
    public void WriteLine(string line)
    {
        Console.WriteLine(line);
    }
}

像这样分解应用程序

public static void Main()
{
    IOutputWriter consoleOut = new ConsoleWriter();
    WriteHelloWorldToOutput(consoleOut);
}

public static void WriteHelloWorldToOutput(IOutputWriter output)
{
    output.WriteLine("Hello World");
}

现在，您有了一个指向该方法的注入点，该方法允许您使用您选择的模拟框架来断言使用“Hello World”参数调用 WriteLine 方法。

我尚未解决的问题（我对输入感兴趣）：

1. 如何测试 ConsoleWriter 类，我想你仍然需要一些 UI 测试框架来实现这一点，如果你有这个，那么整个问题就在无论如何都没有实际意义...

2. 测试主要内容方法。

3. 为什么我觉得我通过将一行未经测试的代码更改为七行代码而取得了一些成就，其中只有一行代码经过了实际测试（尽管我猜覆盖率已经上升了）

Answer 6

假设您了解单元测试，并且假设您了解 tdd“红绿重构过程”（因为您说过您熟悉 TDD），我将快速解释典型的 tdd 思维过程。

如果您考虑某个特定的问题单元，并且应该根据依赖关系来考虑所有其他相关事物，那么您的 TDD 生活将会变得更加轻松。 这是一个示例

场景：-
我希望我的程序在控制台上显示 hello world。

tdd 思考过程：-

“我认为我的程序将开始运行，然后调用控制台程序将我的消息传递给它，然后我希望我的控制台程序将其显示在屏幕上”

“所以我需要在运行程序时进行测试，它应该调用控制台程序“

”现在有哪些依赖项？嗯，我知道控制台程序是其中之一，我不需要担心控制台如何将消息发送到屏幕（调用io设备，打印和所有这些）我只需要知道我的程序成功调用了控制台程序，我需要相信控制台程序可以工作，如果没有，那么目前我不负责测试并确保它工作。我想测试的责任是我的程序在启动时调用控制台程序“

”，但我什至不知道要调用哪个控制台程序，但我知道 System.console.Writeline （具体实现）。那么，由于需求的变化，这可能会在未来发生变化，那么我该怎么办？”

“好吧，我将依赖于接口（或抽象）而不是具体实现，然后我可以创建一个假控制台来实现我可以测试的接口”

  public interface Iconsole
    {
       void WriteToConsole(string msg);
    }



 public class FakeConsole : Iconsole
    {
        public bool IsCalled = false;

        public void WriteToConsole(string msg)
        {
            IsCalled = true;
        }
    }

我已经放置了 IsCalled 成员，如果控制台程序发生，其“状态”将会改变被称为

“好吧”，我知道这听起来像是一个漫长的思考过程，但它确实得到了回报。 Tdd 迫使您在编码之前思考哪个比在思考之前编码更好

最终，您可能会想出类似以下方式来调用您的程序：

var console = new FakeConsole();
    console.IsCalled = false;
    my_program program = new my_program(console);
    program.greet();

我将控制台传递给 my_program，以便 my_program 将使用控制台来编写我们的信息显示在屏幕上。

我的 my_program 可能如下所示：

public class my_program
    {

        Iconsole _consol;
        public my_program(Iconsole consol)
        {
            if (consol != null)
                _consol = consol;
        }
        public void greet()
        {
            _consol.WriteToConsole("Hello world");
        }
    }

最终的单元测试将是：-

 [TestMethod]
        public void myProgramShouldDisplayHelloWorldToTheConsole()
        {
            //arrange

            var console = new FakeConsole();
            console.IsCalled = false;
            my_program program = new my_program(console);
           //act
            program.greet();

            //assert
            Assert.AreEqual(true, console.IsCalled, " console was not called to display the greeting");



        }

Answer 7

在 java 中，您可以捕获（“重定向”）System.out 流并读取其内容。 我确信在 C# 中也可以完成同样的事情。 java中只有几行代码，所以我确信C#中不会多出多少行代码

Answer 8

我真的不得不反对这个问题！ 所有方法论都有其用武之地，TDD 在很多地方都表现出色。 但用户界面是我真正放弃 TDD 的第一个地方。 在我看来，这是 MVC 设计模式的最佳理由之一：以编程方式测试模型和控制器的性能； 目视检查您的视图。 您所说的是对数据“Hello World”进行硬编码并测试它是否到达控制台。 要使用相同的源语言进行此测试，您几乎必须虚拟控制台对象，这是唯一可以执行任何操作的对象。

或者，您可以在 bash 中编写测试脚本：

echo `java HelloWorldProgram`|grep -c "^Hello World$"

添加到 JUnit 测试套件有点困难，但有些事情告诉我这从来都不是计划......

Answer 9

我同意大卫·伯杰的观点； 分离接口，并对模型进行测试。 在这种情况下，“模型”似乎是一个返回“Hello, world!”的简单类。 测试看起来像这样（在 Java 中）：

  Greeter greeter = new Greeter();
  assertEquals("Hello World!", greeter.greet());

我在 http://ziroby.wordpress.com/2010/04/18/tdd_hello_world/ 。

Answer 10

我猜是这样的：

using NUnit.Framework;
using System.Diagnostics;

[TestFixture]
public class MyTestClass {
    [Test]
    public void SayHello() {
        string greet = "Hello World!";
        Debug.WriteLine(greet);
        Assert.AreEqual("Hello World!", greet);
    }
}