How can I write a unit test for a controller class

Question

Has anyone been able to successfully unit test methods that are, by necessity, coupled to the System.Windows.Forms.Form class?

I've recently been working on a C# winforms application, trying to build it with an MVC structure. This is difficult enough, given that the framework isn't really built with this in mind.

However, it gets even tougher when you throw unit testing into the mix. I've been making sure that my controllers are not coupled to concrete view classes, so that I can use a stub/mock for unit testing. But referencing the Form class somewhere is unavoidable, and these methods do need to be tested.

I've been using Moq because it has some nice type-safety features, and allows mocking concrete types. But unfortunately, it doesn't allow me to "expect" calls to methods or properties on a concrete type that are neither virtual nor abstract. And since the Form class was not built with subclassing in mind, this is a big problem. I need to be able to mock the Form class to prevent real windows from being created, by "expecting" ShowDialog, for example.

So I'm left unable to run any unit tests that do much interaction with subclasses of Form, which my views are.

Is there anyone out there who has successfully unit tested this type of code? How did you do it?

Is this something that other mocking frameworks can get around? Would the string-based methods used by other mocking frameworks be subject to the same constraints? Can I write my own explicit long-hand mock classes, or will the lack of virtual members prevent me from being able to suppress the window behavior that way too?

Or is there some way I haven't thought of to structure my classes so that the Forms-coupled code ends up in methods and classes of trivial complexity, such that I can get away without explicitly unit testing them, without my conscience beating me up for it?

Answer 1

The best method I've heard of/used for unit testing with GUI elements is the Humble Dialog pattern/method. In essence, the Forms are just the interface, and all the real work is done in other classes. You unit test the classes that provide the functionality, and then just tie your GUI events to the appropriate methods in those classes.

Answer 2

My current thought is that I may have to use composition rather than inheritance with the Form class, to decouple the controllers from it.

This has the disadvantage that every time I need to use an member of the Form class that I didn't plan for, I need to add it explicitly to my view interface.