I am 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.
Related
I am currently developing for Silverlight 4.0 and after mostly creating class libraries with TDD in usual C# (before SL) I can say that my current process is way slower than I am used to. (I think this can be said about any UI code compared to library classes, but here I think its really serious issue for me.)
I am wondering what techniques can be recommended to increase SL development performance.
I am mainly concerned about hard to test code (from my POV) - MVVM & UI - what can be done to improve performance here, I am thinking maybe theres a way to use a smaller sandbox somehow and test/debug control behaviour outside of scope of whole application, its pretty clear to me that me running whole application to test whether a new dialog box works correctly isnt fastest way and I could improve performance if I had a way to test this dialog alone for example, and there are probably other ways I cannot think of that can be a solution too.
EDIT: 1)here is something that I found useful , for TDD there is now a project that allows console runner to run tests so you dont have to run silverlight tests in browser & can integrate in your build process LightHouse
2) found following page, it provides some idea about a possible approach one could use to test view:
http://fohjin.blogspot.com/2008/09/how-to-test-your-xaml-behavior-using.html
there is no magic beautiful way and this one can be utilized but having to name all controls for example is a must to get this to work which isnt very good often
Statlight for the build server.
AgUnit to allow resharper to run silverlight tests.
WebAii for automation testing.
I'm not a fan of SLUT, as to run an individual test you have to cut and paste its name, and it doesnt remember it until you let it run all the way through, which I rarely do if I'm debugging.
Have you tried to use slut?
http://archive.msdn.microsoft.com/silverlightut
she will do what you want and pretend she enjoys it
I am developing a silverlight application for the past 6 months using prism framework. When I look at the code base now it has grown huge with lots of modules, event aggregators, inter module communication code etc. On hindsight I am contemplating whether I made the right choice. Is there any other simpler framework I should have gone for ?
Prism is at its best when targeting a large application. Why? Because the core concepts Prism provides, such as Modularity, UI Composition, support for MVVM, etc. are used the most in this kind of applications.
The idea, as you said, is that you are likely to end up with a bunch of modules. The benefit of that is that your application is decoupled, and modules can be tested in absolute isolation so they are easy to maintain.
By using Prism, or any other library/framework that modularizes your application, (correctly) in large applications, you don't need to go through your entire application looking for bugs when you make a change to one of the parts. This is not true in monolithic applications, where making a minor change might bring down the entire app.
Another plus for Prism in this scenarios is that it allows multiple teams to work on different modules simultaneously, without affecting each other's work. This is specially useful when working with distributed teams.
The thing that would convince you of making the right choice, would be comparing the application you created with the same one but with high coupling of its components.
I hope this helps
I'm starting a new WPF/Silverlight custom control project and wanted to do unit testing on this one. However I'm a little confused about how to approach this.
This control would be based on the same codebase for both WPF and Silverlight with minor forking using #ifs and partial classes to tame the differences. I guess I could write unit tests for WPF part with NUnit, MSTest, xUnit, etc. and for the Silverlight part with Silverlight Unit Test Framework but this doesn't sound very elegant to me. I'd have to either ignore testing identical code on one of the platforms and test only differing parts (which is not very trustworthy) or rewrite tests for 2 frameworks (which is annoying). Is this the right way to go?
I'm wondering if there's some guidance, articles, tutorials out there on how to approach this task. Any pointers?
I am hardly an expert in WPF and Silverlight, but wouldn't it be possible to write the tests using the same techniques as the production code (#ifs and partial classes as you said)?
I tried to use xUnit first but it was kind of complicated to make same tests work in xUnit and SLUT (different attributes, syntax, etc.)
Then I did some basic experimenting with MSTest and from very simple test it looks like you can successfully use MSTest for the WPF part and same code with some #ifs, etc. and SLUT for the Silverlight part. So I'll try to go this route and see how it works in real-world situations.
I'm developing a project using the MVVM pattern in WPF.
One of the key benefits to MVVM is maintaining clear separation between business logic and presentation.
As a test to see how well separated everything actually was, over the weekend I spiked moving all ViewModels, Models, and business logic to a separate .dll. The .exe was left as a thin presentation layer.
This worked, seamlessly, first try.
I've already seen benefits to keeping views (xaml, presentation) in the .exe and core logic in its own dll. For example, there's no longer any dilemma in my mind about whether code-behind in Xaml is an issue: I'm comfortable with it if it becomes necessary, since I know it's presentation specific.
So far this exe/dll separation has worked so well that my question is: Has anyone experienced any downside to this approach?
Related question: Implementing MVVM in WPF without using System.Windows.Input.ICommand
We use this kind of separation in all of our products because it helps us to see if any code violates against the UI - business logic separation.
Most times we do it the same way as you have suggested:
Sample.Presentation.exe (Contains all the WPF stuff, thin assembly)
Sample.Applications.dll (Is responsible to the application's workflow, here are all ViewModels)
Sample.Domain.dll (Here are the business rules)
We don't have encountered any issues yet and I don't expect to see any problems in future.
I don't see any spcific issues with this approach besides the general pro/con for using few/many projects.
2 weeks now with my Model & View Models in a dll, my xaml in an exe and no problems whatsoever.
The actual question is ... what are assembles for?
They are a way to separate logic making it unavailable to other code unless you add a reference, so in fact they are a way of hiding parts of code from other parts.
Given this purpose and the way you are using it I would say that you're doing it right.
Having said that I find much easier to verify that the Views do not have any code behind in code reviews and keep the views in the same assembly. Less projects = faster compile and load times.
Couple of year ago I when to work for company as web developer. It has my first Sirius web development job, (ASPx/C#) so it has very exciting and I learned a lot about that world, from the developer point of view.
In that group we had a concept for the pages where loaded in the page UC’s (User controls), I don’t know if it’s the same in every web development team with every language, I’ll assume it is so.
The contract ended and I came back to develop win32 “winForm” application.
But since them I have tried to apply the same principle for my win32 development I learn there, meaning having bunch of UC’s (Visual User controls) that I load in the form.
They are regular visual components, not loaded in the toolbox, code is available in the project, but the component is not developed in the form, they are loaded there.
I would like to know opinions about this approach, what other are doing similar or better to this And improvements that can help us to speed up development and increase code reuse, because that is what this is all about.
If you're using the layout components in Winforms, this might be an acceptable approach although I think the thing that distinguishes the web and Windows Forms (note: NOT WPF!) is that in the former you do a lot of "compositing" which is why the UserControl concept is so useful whereas in the latter you operate on very sophisticated controls (e.g. 3rd party - in my last gig we used an incredible grid control via a small company called Infralution)
The main problem I would see is with layouts since the rendering model is a little different than the web. I know nothing about your application but if it "works" that is what is most important. I assume in this case you use things like the FlowLayoutPanel and the TableLayoutPanel properly.
If you want to go a more canonical route, take a look beyond simply creating components at how you can use the inheritance model to composite your application in a more robust way - having a base Form class that has containers for where your "UserControl" type components go and then using some kind of interface based dependency injection to swap them out while the application is running.
Finally, take a look at some of the open source Windows Forms applications out there to see if you're being too hard on yourself since common UI and reusable components are a goal in every application. Even though I've always thought Microsoft's Patterns & Practices stuff teetered towards being bloated, there are some good ideas and you should study some of the approaches of the Composite UI Application Block they put out.
Okay, not finally, there's one more thing I'd like to add: take a long hard look at WPF which will bring back a lot of the concepts from your web development days and give you that kind of power in a desktop application.