Lazy User Interface Part I

I was recently working on code that deals mostly with the front-end portion of our software.
Before I began the task, I glanced over the wire frames, opened up the designer, dragged and dropped a few controls here and there, changed a few properties, and added some methods to handle the business logic. Before lunch, the task was complete.

Something just did not feel right about this task. I noticed that the time I spent writing and running unit tests was significantly less than usual. At first I dismissed the thought because I convinced myself most of the code was UI related, so no need to test. After work, I decided to take another look. I started at the presenter level (we use MVP pattern), and noticed very little code was in the presenter, and the view seemed to be much larger. Since we practice TDD at work, how could this happen?

Part of the problem was that I started the code at the UI level instead of the presenter level. The problem with starting the code at the view level is because everything seems to belong inside the view. For example, when the user right clicks on the grid, it will show a context menu and the items enabled in the context menu are dependent on what the user has selected on the grid. Pretty simple scenario, right? When I worked on this part, I enabled the context menu items in the view because it seems like the view should be responsible for it. After all, context menu it is a visual thing. In order to figure out which context menu items to enable, I need to figure out what the user has selected. How can the view retrieve the data? Oh wait, the grid is DataBound. Perfect! All I have to do is peak at the BindingSource to figure out which context menu to enable. The problem now is that I do not have unit tests to prove the context menu is correctly enabling the items. Since all the code lives in the view, I have no way to tell what is enabled in the context menu without spinning up the view.

If I start at the view level a lot of the code seems to belong in the view instead of the presenter. There is nothing wrong with adding code in the view, as long as it does not stop you from writing unit tests and has proper separation. The view should be responsible for all UI renderings such as popping up a message box or drawing something on the form. Everything else, in my opinion, should belong in the presenter which makes the code testable. In the next few posts I will use a simple application to address how to write testable UI using the MVP pattern with TDD.