A full chapter is over and I have only completed the first story. So what have I been up to? Well, actually, writing the code in this chapter didn't take that long. I didn't measure the time, but I estimate it has taken me about half a day.
I've spent a lot of time working on getting the tests look right. And if I may say so, it looks quite promising. While there's still room for improvement (which probably is a good sign), I believe I have a nice foundation for future tests.
Here's what the test foundation look like.
I have the test fixture where the feature, or the behavior of the functionality, is described. Then there's a layer below it with infrastructure code containing the fakes. The infrastructure layer provides a robustness for the tests in the sense that, if some implementation detail would change, the tests are likely to remain unchanged. We saw a small example when I renamed Thingy to Application. This change only affected the infrastructure layer. Later we will see examples of bigger changes.
Is it worth spending all this time, investing in this infrastructure? The word "invest" suggests that it might be. And I would say that it definitely is so. Michael Feathers, in his book Working Effectively with Legacy Code, defines legacy code as code without tests. I would like to add a few conditions about the tests to that definition. One is that the tests must be robust. If changing the production code requires you to change the test code at the same time, then what good are the tests as a safety net? By investing in this test infrastructure, I make sure that the code will not become legacy.
Furthermore, we will later notice that the test infrastructure will help me speed up the writing of new tests. Once I have a convention to follow for my tests, where most or the entire test infrastructure is already written, it will take but a couple of minutes to write a new, high quality test.
Looking at the SongsView, I think I've managed quite well to make it thin as well. Here it is.
public partial class SongsView : Form, ISongsView { public event Action OnCloseButtonClick; public event Action OnViewClosed; public SongsView() { InitializeComponent(); } public ReadOnlyCollection<Song> Songs { set { _songs.DataSource = value; } } public void ShowView() { Show(); } public void CloseView() { Close(); } private void SongsViewFormClosed( object sender, FormClosedEventArgs e) { OnViewClosed.Raise(); } private void CloseButtonClick( object sender, EventArgs e) { OnCloseButtonClick.Raise(); } }All properties and methods are one-liners, doing only one thing. The public methods delegate the calls to the .NET framework in the simplest way. The private event handler methods raise an event in (almost) the simplest possible way.
One reflection I have made is that, despite the test suite, I do quite a lot of manual testing. Before I check in the code, I always run the application to make sure it works fine. I don't do a full regression test of all functionality, but it's more of a smoke test to see if the application crashes and burns.
There are plenty of UI testing tools that can help me with this, that will fire up the application including the real UI for me. And it would be a good idea to start using one of them. It is difficult to replace the test suite that I have created so far using only one of these tools, since they can only access the information presented to the user. Also, they tend to be very slow, in comparison. But as a complement, for smoke testing, it works really fine.