TestExplorerWindow, the event-tossing UI

Following up on Integrating Unit Testing functionality into an old COM-based IDE, I made quite a few changes to the UI, and now the code-behind for my TestExplorerWindow is starting to feel somewhat bloated, at least compared to what it was... I blame the added toolbar and the fancypants progressbar.

At least it looks pretty:

Here's the less pretty code-behind - the WriteResult method is the ITestOutput interface implementation - I'm starting to question whether it's needed at all, and whether I actually need all these events:

```
namespace RetailCoderVBE.UnitTesting.UI
{
internal partial class TestExplorerWindow : Form, ITestOutput
{
private BindingList _allTests; // all tests found in solution
private IList _tests; // tests to execute

public TestExplorerWindow()
{
_allTests = new BindingList();
_tests = new List();

InitializeComponent();
InitializeGrid();
RegisterUIEvents();
}

private void InitializeGrid()
{
testOutputGridView.DataSource = _allTests;

var messageColumn = testOutputGridView.Columns
.Cast()
.FirstOrDefault(column => column.HeaderText == "Message");
if (messageColumn != null)
{
messageColumn.AutoSizeMode = DataGridViewAutoSizeColumnMode.Fill;
}
}

private void RegisterUIEvents()
{
FormClosing += TestExplorerWindowFormClosing;

testOutputGridView.CellDoubleClick += GridCellDoubleClicked;
testOutputGridView.SelectionChanged += GridSelectionChanged;

gotoSelectionButton.Click += GotoSelectionButtonClicked;
addTestMethodButton.Click += AddTestMethodButtonClicked;
addTestModuleButton.Click += AddTestModuleButtonClicked;
addExpectedErrorTestMet

And I've written an extension method to convert a TestResult to an icon, fetched from project resources

This is an abuse of extension methods. TestResult is a class that you wrote. Extensions are for extending classes that we can't modify. There's no reason to write an extension method for a class that you have complete control over. TestResult should implement this directly.

I'm going to risk some general hand waving here, but...

In my mind, anything that's inheriting from Form or Control should be dead dumb simple. It should raise events and provide some properties that a separate class can set. Those properties are then wired into the actual UI for display. There's should be very little logic at this level of the application. That logic isn't easily testable when it's bound up in your UI.

A more proper architecture would look something like this diagram.

This allows you to mock up a TestExplorerView and test the logic that now lies in the controller.

StackExchange Code Review Q#68456, answer score: 5