Before I write any test, I like to experiment a bit with the production code. What is it that I want to accomplish? What might the final result look like?
So I start by creating a new WinForms project and I get the following generated Main() method in the Program class:
public static class Program { [STAThread] public static void Main() { System.Windows.Forms.Application.EnableVisualStyles(); System.Windows.Forms.Application.SetCompatibleTextRenderingDefault( false ); System.Windows.Forms.Application.Run( new Form1()); } }The first two lines in the Main() method specify some kind of behavior of the application, and the last line create the window, represented by Form1, and opens it by passing it to the Run() method. These lines are not that important for this book, so I won't explain them in detail. However, when developing code, it is extremely important to understand all your code, including auto-generated code. So obviously I ensure that these lines are something I want to keep.
I'm going to test drive this application and I want to have as much code as possible covered by test. But not at any cost. These static calls to the Application class look quite complicated to include in a test and will probably stay unchanged for the whole application lifetime. So instead I would like to start testing where Form1() is created.
One problem with WinForms (and many other UI frameworks) is that it is really complicated to test. Form1 derives from the class Form and that code is something you don't want to execute in a test since it typically means that you need to display the window when running your tests. This is slow, might give unexpected behavior if you interact with the computer while the tests are running, and might not even be possible in environments such as a build server. The controls and their event handlers are typically private so you would have to resort either to reflection or to change private into protected and create a sub class of the Form to be able to, for instance, simulate a button click.
These are enough reasons for me to want to look for a different solution. Luckily, the Run() method supports another parameter, and that is an ApplicationContext. So I can pass in something that derives from ApplicationContext, something that I can also test.
So I would like the Main() method to look something like this:
public static class Program { [STAThread] public static void Main() { System.Windows.Forms.Application.EnableVisualStyles(); System.Windows.Forms.Application.SetCompatibleTextRenderingDefault( false ); System.Windows.Forms.Application.Run( new Thingy(...)); } }Here, Thingy is the ApplicationContext derivative. Not the best name for a class, perhaps, but so far I have no idea what kind of class it is, and what kind of responsibility it will have, so I just give it a dummy name that I will change later when I have more knowledge. All I know now is that, in some way, this class should open the songs window Form.
The solution using ApplicationContext does not remove the problem with the hard-to-test Form though, but rather moves it. Luckily to a more convenient place. Since the code inside the Form derivative cannot be tested I need to fake it in some way in my tests. I do this by introducing an interface, ISongsView, that Thingy will communicate with and that has a fake implementation in the tests.
Since the real implementation is untested it must be as thin and stupid as possible, containing no UI logic at all. What it should do is that it should just pass on events elsewhere and expose trivial methods for changing the UI state. The pattern I follow is called the the Humble Dialog box pattern.
With these thoughts in mind I undo the sketch code and start writing my first test, a test that verifies that the songs window is displayed when the application starts. I create a fake for the songs view and pass it to the Thingy constructor. Then I make an assertion that the view's ShowView() method has been called.
[TestFixture] public class SongsFixture { [Test] public void Songs_window_is_displayed_when_the_application_starts() { var view = new SongsViewFake(); new Thingy(view); Assert.That(view.HasBeenShown, Is.True); } } public class SongsViewFake : ISongsView { public bool HasBeenShown { get; private set; } public SongsViewFake() { HasBeenShown = false; } public void ShowView() { HasBeenShown = true; } }If you are a java developer you probably wonder about the var type that I declare view as. C# uses a feature called type inference which means that if the compiler can figure out the type you don't have to specify it, but instead specify the type as var. In this case, the type is specified after the new keyword: SongsViewFake.
Also, you might wonder about the declaration of HasBeenShown in the SongsViewFake. This is called an auto property. First of all, C# has something called properties which is a short way of creating getHasBeenShown() and setHasBeenShown() methods. There will be examples of those further on. The auto property is a propery and a field combined, that is, a property that implicitly contains a field. An equivalent to the HasBeenShown auto property is a normal property that does nothing but get and set a field in its implementation.
As I create the test I simultaneously create stubs in the production code to remove compile errors.
public class Thingy { public Thingy(ISongsView view) { } } public interface ISongsView { void ShowView(); }Now the code is free from compile errors, so I run the test and notice that it is red. Just as expected.
I've made it a habit of always running the tests and see them red before I start with the implementation. This is to make sure that it is red as expected and that it is red for the expected reason. Also, I check that the failure message is informative and makes sense.
In the context "Songs window is displayed when the application starts" I expected true but it was false. I would say that this message is quite clear, so I leave it as is.
Writing the code to make it pass is really trivial.
public class Thingy { public Thingy(ISongsView view) { view.ShowView(); } }Now that the test is green I can start using my Thingy class in the Main() method and so I write almost the same code as I sketched previously. Also, I change so that Thingy derives from ApplicationContext.
I also create the SongsView and make sure it implements the ISongsView interface.
public static class Program { [STAThread] public static void Main() { System.Windows.Forms.Application.EnableVisualStyles(); System.Windows.Forms.Application.SetCompatibleTextRenderingDefault( false ); System.Windows.Forms.Application.Run( new Thingy( new SongsView())); } } public class Thingy : ApplicationContext { ... } public partial class SongsView : Form, ISongsView { public SongsView() { InitializeComponent(); } public void ShowView() { Show(); } }I run the application and it looks nice.
There is one thing, though, that I don't like about the code I just wrote, and that is that the Thingy constructor contains logic. The responsibility of a constructor is to initialize the object. If it does more than that, which it does when having logic, it violates the Single Responsibility Principle. Right now it's quite harmless, but later I'll probably run into problems. So my next task will be to move that logic to a method.
The Single Responsibility Principle (SRP), if you wonder, says that there should never be more than one reason for a class to change. I will give you plenty of examples of what that means further on. And although the definition talks about classes, the same rule applies for methods as well, which is what I base my argumentation on here. Basically, it says that a method should only do one thing. And a constructor's thing is, as I mentioned, to initialize the object.
One could argue whether I should really care about this now, or if I should wait until I actually run into problems. And it is a good question. My standpoint is that one should always choose the currently simplest solution that also adheres to proven design principles. (Note that simple does not necessarily mean easy.) In this case, moving the logic from the constructor to a separate method will not add any extra complexity to the code. However, doing so I will follow the design principle of not having logic in a constructor.
Before I start with the refactoring, I check in my code into the version control system.