“Hello World” - The TDD way?

Question

Well I have been thinking about this for a while, ever since I was introduced to TDD. Which would be the best way to build a \"Hello World\" application ? which would print \"H

Answer 1

Presenter-View? (model doesn't seem strictly necessary)

View would be a class that passes the output to the console (simple single-line methods)

Presenter is the interface that calls view.ShowText("Hello World"), you can test this by providing a stub view.

For productivity though, I'd just write the damn program :)

A single test should suffice (in pseudocode):

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

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

Assert.IsTrue( view.MethodsCalled );

Answer 2

Well...I've not seen a TDD version of hello world. But, to see a similarly simple problem that's been approached with TDD and manageability in mind, you could take a look at Enterprise FizzBuzz (code). At least this will allow you to see the level of over-engineering you could possibly achieve in a hello world.

Answer 3

In java you could capture ("redirect") the System.out stream and read its contents. I'm sure the same could be done in C#. It's only a few lines of code in java, so I'm sure it won't be much more in C#

Answer 4

I agree with David Berger; separate off the interface, and test the model. It seems like the "model" in this case is a simple class that returns "Hello, world!". The test would look like this (in Java):

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

I've created a write up of solving Hello World TDD style at http://ziroby.wordpress.com/2010/04/18/tdd_hello_world/ .

Answer 5

Pseudo-code:

• Create a mock of something that accepts a stream.
• Invoke helloworld onto this mock through some sort of dependency injection (Like a constructor argument).
• Verify that the "Hello World" string was streamed into your mock.

In production code, you use the prompt instead of the mock.

Rule of thumb:

• Define your success criteria in how the component interacts with other stuff, not just how it interacts with you. TDD focuses on external behavior.
• Set up the environment (mocks) to handle the chain of events.
• Run it.
• Verify.

Answer 6

Assuming you know unit testing, and asuming you understand the tdd "red green refactor process" (since you said you are familiar with TDD) Ill quickly explain a typical tdd thought process.

Your TDD life will be made a lot easier if you think of a particular unit of problem and every other connected things should be thought of in terms of dependencies. here is a sample

scenario:- I want my program to display hello world on the console.

tdd thought process:-

"I think my program will start running then call the console program passing my message to it and then I expect my console program to display it on the screen"

"so i need to test that when i run my program, it should call the console program "

"now what are the dependencies? hmm I know that the console program is one of them. I don't need to worry about how the console will get the message to the screen (calling the io device, printing and all that) I just need to know that my program successfully called the console program. I need to trust that the console program works and if it doesn't, then at the moment i am not responsible for testing and making sure it works. the responsibility I want to test is that my program when it starts up calls the console program. "

"but i don't even know exactly what console program to call. well I know of System.console.Writeline (concrete implementation) but then this may change in future due to change in requirements, so what do i do?"

"Well , I will depend on interface (or abstraction) rather than concrete implementation, then i can create a fake console implementing the interface which i can test against"

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



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

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

I have put IsCalled member whose "state" will change if whe ever the console program is called

OK I know it sounds like a long thought process but it does pay off. Tdd forces you to think before codeing which is better then coding before thinking

At the end of the day, you may then come up with something like the following way to invoke your program:

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

I passed console to my_program so that my_program will use console to write our message to the screen.

and my my_program may look like this:

public class my_program
    {

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

the final unit test will then be :-

 [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");



        }