I a开发者_如何学JAVAm developing quite complex .NET custom control (40K lines of code) but have some trouble testing it.
I have done several sample projects demonstrating main features of the control, but one can test only small subset of control states and operations.
Unit tests are also useless, because of these problems:
- tremendous number of use cases (e.g. describing "item selections" can take some 4 pages of specs)
- many ways of doing the same thing (and also from user-code or GUI)
- the control have many states a sub-states, and anything may not possibly work in every state
- how to test design-time support?
I know this is a common problem of GUI testing, so I would like to ask you if there are any well-estabilished practices of testing custom visual components?
Thanks for any advice.
The main thing is to limit the GUI testing to a minimum, because it's the most expensive way to test. In 40K lines of code I bet 90% of code doesn't really work with the WinForm GUI elements at all. So most of it could be covered by unit tests, but this depends on the way you structured your code.
Things to consider:
- SOLID principles, especially the Single responsibility principle (SRP) - instead of a couple of huge "God" classes, you should rely on a large number of small "service" interfaces & classes which only do one thing and do it well. You can write isolated tests for these and then assemble them into a larger picture once you know they work OK.
- MVP pattern (Passive View actually): the WinForm GUI code should be only a thin layer (View), everything else should be in Presenters and the Model.
- Presenter First approach.
I work on a relatively complex WinForms application and these patterns have never failed me.
As for GUI testing, I use UI Automation, but only for some standard cases. Everything else is covered by non-GUI unit testing.
精彩评论