My last test didn't result in any revelations regarding the design, so without further ado I add another test. This time I want to make sure the OK button closes the add song window.
[Test] public void Clicking_ok_closes_add_song_window() { Application .Start(view => { view.ClickAddButton(addView => { addView.ClickOkButton(); Assert.That(addView.HasBeenClosed, Is.True); }); view.ClickCloseButton(); }); } public class AddSongViewFake : IAddSongView { public event Action OnOkButtonClick; // ... public void ClickOkButton() { OnOkButtonClick.Raise(); } }Running the test gives the failure that there are no listeners to the event. So I add the event to the view interface and the real view.
public interface IAddSongView { event Action OnOkButtonClick; // ... } public partial class AddSongView : Form, IAddSongView { public event Action OnOkButtonClick; // ... private void OkButtonClick( object sender, EventArgs e) { OnOkButtonClick.Raise(); } }I first subscribe to the event with an empty handler to see that the failure message is descriptive, which it is. Next I make the test pass by letting the handler call CloseView() on the view.
public class AddSongShower { // ... public void Show() { View.SongTitle = string .Empty; View.OnOkButtonClick += View.CloseView; View.OnCancelButtonClick += View.CloseView; View.ShowView(); } }And the test is green, as expected. Manually testing the application I also notice that the ok button is closing the window, as expected. So I check in my code.
One thing that might have bothered you with this test, and possibly some other tests I have written, is the duplication. Comparing this test with the Clicking_cancel_closes_add_song_window() test, out of ten lines of code, nine are identical. The only line that differs is what button I click to close the view.
It's good that you noticed this! Duplication is indeed something to watch out for in all forms. There is, however, one thing that I value higher than avoiding duplication, and that is readability. Reading code is probably the activity any programmer spend most time on, even when implementing new functionality, and if I can improve the readability I will undoubtedly increase the productivity.
Most of the time, readability and duplication removal are not at odds. One place where they more often than other do compete with each other is, however, in test code. Removing duplication often means introducing an abstraction, and not all abstractions are easy to read and understand.
In this case I could quite easily reduce the duplication, though. I could, for instance, create a method on ApplicationFake called StartAndOpenAddSongWindow(), like this:
Application .StartAndOpenAddSongWindow(addView => { addView.ClickOkButton(); Assert.That(addView.HasBeenClosed, Is.True); });The StartAndOpenAddSongWindow() method now contains the logic to start the application and clicking on the add button. This is definitely a great tool to use, and I will probably use it later on. However, I don't want a zillion helper methods on ApplicationFake, so I would like to see what clusters of functionality appear before I do this. That is, I wait until I have a few more tests.
One could argue that the assertion in the example above should also be moved into the StartAndOpenAddSongWindow() since both the ok and cancel tests contain it. However, the assertion is, as I have mentioned previously, very important to have inside the test method for it to make sense. Moving it would require the reader to navigate away from the test in order to understand the test.