TDD / Unit testing a windows application?
I'm very new to doing any type of testing, but I've done a little reading and it seems like its a great way to go. I love the idea of being able to just click a button and ensure that the codebase is stable. The freedom to hack away as long as the tests pass is very intriguing.
However, my software is a windows based program. Basically what it does is interact with other windows on the users desktop, and move them around the screen based on certain criteria. If XX image is visible, move that window to x/y coords. If F9 keyboard shortcut is pressed on that window, m开发者_如何学运维ove it to x2/y2 coords. Etc.
I'm at a loss as to how I would go about any sort of testing. Any help is appreciated.
Since you mentioned that you're a beginner, I'll add a reminder here, that you need to be careful of what you test. You wish to test your logic, not windows. In order to do this, you need to separate your concerns into a class (or classes) that contain your logic, and classes that contain wrappers (proxies) to APIs that you use - you don't test the APIs. They work until you prove otherwise.
You will want to test your classes, and stub or mock the proxies. In the above example, if for example, you're using the Windows API commands to deliver your solution, you'll put the commands that move the window into a WindowsProxy class, and mock the calls, verifying that the calls to them are made, but not actually running them in the test.
If you are using .NET, and Windows-Forms, or some similar framework, you'll want to use a pattern that supports testing, such as MVP. You'l want to write your tests to exercise the Presenter, while stubbing or mocking the View (your window) and the Model (any API or domain object you use).
Here's a sample architecture:
public interface IView { ... }
public class View : IView
{
private Presenter _p;
View()
{
_p = new Presenter(this);
...
}
}
public class Presenter
{
presenter IView _v;
Presenter(IView view)
{
_v = view;
}
}
Using a mocking framework like Moq, you can easily stub and mock the view, and test the presenter (where all your logic will reside). With Moq, you can have the class under test set values on the mock, and later verify their values (e.g. the coordinates of the window).
Hope this helps. I spend a lot of my time developing Win-Form based custom controls, and develop them with TDD. It is not impossible or even difficult, once you get the hang of it.
Let me know if you need any further elaboration.
Assaf.
It's not recommended to UnitTest windows so you'd better to refactor your app to Model-View-Controller(any kind of this pattern) and test the Controller and Model classes standalone.
In order to do unit testing of this type of application, you need to distinguish between testing what you see on the screen, and testing the state of the application.
If I take one of your examples:
If F9 keyboard shortcut is pressed on that window, move it to x2/y2
You could structure your code so that you can easily trigger the function/method to move the window. Then you would want to interrogate the window state and determine where it is. If the window state reports that it is at position x2/y2, that's a positive result.
There is a lot of value in these types of tests. Of course there's always a chance that where the window thinks it is, and where it actually appears might not match. So you should still do some testing where you are clicking buttons and looking at the screen. You just don't need to do all your testing like that.
精彩评论