Regression Testing Functionality Of Code In Button Press?

Question

I have to run the code inside of my button_Click method to do regression testing, but since the method is private, I can't simply call it from my regression testing assembly.

private void button_Click(object sender, EventArgs e){
    //Does stuff
}

What is the best approach to take from here? I have two ideas:

1. Put the contents of button_Click into a separate public method
2. Make button_Click a public method

I'm leaning more towards option 1, as it helps create more separation between the UI and business logic. Maybe there's an even better way to solve this problem?

Addendum:

Ok, so here is a simple example where I use a "thin" UI layer. Am I understanding this correctly? The RefreshForms method is part of the forms code, but put into it's own method to keep the button_Click method as thin as possible.

Then, the QA code only tests the business logic, and all is well?

Form Code:

private void button_Click(object sender, EventArgs e){
    int res = BusinessLogic.SquareIt(Convert.ToDouble(textBox1.Text));
    RefreshForms(res);
}

public void RefreshForms(){
    textBoxRes = res.ToString();
}

BusinessLogic Code:

public void SquareIt(double input){
    return Math.Pow(input, 2);
}

QA Code:

[Test]
public void RunTest(){
    Assert.AreEqual(BusinessLogic.SquareIt(3),9);
}

Answer 1

Option 1

The button click method should only be a thin wrapper that makes a call to another method that contains the business logic. You might want to look at the MVP pattern or MVC pattern to help you separate your business logic from you view logic.

Answer 2

Option 3.

Use a test automation framework like WatiN to actually simulate the button getting clicked. I've used WatiN a couple of times and it's actually really easy to use and it's FREE.

Answer 3

As Stuart suggested it is generally a best practice to separate business logic from your UI layer. See http://www.testingmentor.com/imtesty/2010/02/02/api-testing-testing-in-layers/

Ideally, you shouldn't be changing access modifiers for testing purposes. You might also consider protected and internal access modifiers. Also, I would recommend looking at PEX and Moles http://research.microsoft.com/en-us/projects/pex/ from MS Research for testing .NET methods.

If you cannot or do not want to separate the business logic from the event handler, then another option may be to write UI based automated tests using any number of tools or the UIAutomation http://msdn.microsoft.com/en-us/library/ms747327.aspx (assuming this .NET).

Answer 4

I assume your code fragment is Java.

Refactoring the code you want to test into a public method is a nice option, but only if it makes sense for the new method to be public. In other words, if the private method is private for a good reason, you need to make sure you aren't subverting that decision by moving some of the logic into a public method.

Another option is to make the method public and add a comment like "Public for test purposes only".

Another option is to use the reflection API to gain access to the private method. There are some downsides: your code will be longer and harder to read and if someone changes the method signature, your test will still compile, so you won't find out about the problem until your test fails with a cryptic "No such method found" error.