The intent of Model-View-Controller pattern (MVC) is to break UI behavior up into separate pieces in order to increase reuse possibilities and testability. The Controller, which is really the heart of MVC, is the glue that ties the Model and the View together. The Controller receives messages when the user interacts with the View, translates those messages into actions that are performed on the underlying Model, and then updates the View accordingly.
In order to detach logic from the View, we first determine roughly which events / user interactions we think we need to handle. All these events would be prime candidates for methods on the Controller class. Even though the MVC pattern formally states that the Controller should receive the events and act upon the View, it is often more practical to have the View subscribe to the events and then delegate the handling onto the Controller. (This slight variation on the basic MVC is called Model-View-Presenter by Fowler).
The IView interface may expose a property for every possible detail that the Controller needs to access. But this way, you might end up with very large interfaces if the UI has 10 input boxes and you need to be able to control the visibility, enabled, font, back color, fore color, border style, and so on of each of them. To prevent this problem you can create an Adapter / Wrapper [GoF Design Patterns] for each type of UI control you use. The Adapter for a TextBox could expose the mentioned properties, and the View interface would then only have to expose one property of the TextBoxAdapter data type for each TextBox. Behind the scenes, the View would then provide references to the real UI controls to each Adapter during instantiation and the Adapter would simply delegate the call it receives to the actual implementation.
There is one test for each identified method on the Controller.
Life, programming etc. 