I have a scenerio where I have to get some data from the DB and display it in a Grid View in a Win forms app. I have written a unit test for Presenter mocking my repository and view. The test checks that the presenter calls the GetData() method of the repository and then calls the Bind(data) method of the view.
I have also another Integration test for the repository that verifies that if there is some data in the DB it is returned by the repository.
Now comes the part of testing my view. I can think of no way to test my form and check if it indeed binds data to the Grid view but that is a separate question.
My question is that if I wanted to test the above scenario in BDD style then in Win forms there is no way for me to test that when I call a method of the presenter is the Grid View filled with the correct data. Does that mean that I can not do BDD on Win forms as I cannot verify the complete behaviour without mocking the view. If we mock the view then the entire concept of BDD is lost because one key player that is involved in the completion of the scenario is mocked and not real.
It is really confusing for me and don't know if anyone else out there has had similar question in their mind ever.
Yes it is possible to use BDD when creating a winform application.
TestStack have a framework called White. Quoting their website:
White is a framework for automating rich client applications based on
Win32, WinForms, WPF, Silverlight and SWT (Java) platforms. It is .NET
based and does not require the use of any proprietary scripting
languages.
As you are using C# I also strongly recommend you use SpecFlow for your behaviour-driven development; it allows you to define feature and scenarios for your application in a technology agnostic format and creates boilerplate code to aid you in your BDD process.
Here is a good article which works through an example using Specflow for BDD and White for winform automation.
Related
//since I have to get the data from CSV to backend before the application launched. Is there any alternative procedures?
Part of BDD automation best practices is to have the scenarios independent of any backend implementations or other scenarios. In your case, you shouldn't be checking if the service is available in the backend in order to run the scenario.
Or in other words, what would be the user experience if the service id is available in the backend? You may need to consider two scenarios; 1. How does your application behaves when the service id is available in the backend 2. How does it behave when it doesn't.
This is precisely the reason for using either Background of Hooks. Definitions are given below:
Background: Use Background when you want to execute business related pre-conditions to your scenarios like navigate to login page
Hooks: Use Before/After hooks when you have to do some technical setup before/after your scenarios like clearing databast etc...
IMHO, BDD automation should not have any business related logic. The moment you have any logic (e.g. if statements to check business related functions), you need to think if they should be turned into a scenario checking for that condition.
I have developed an application in WPF using MVVM because of the added benefits of seperation and test ability. However I am trying to write some unit tests as part of this but am confused about what to test. I know how to write the unit tests, hovever am unsure of what should I be testing in the view model, which is made up of my properties for data bindings and methods for some logic.
Furthermore most of my view model methods are private because they only need to be accessed from inside of the view model so they cannot be simply tested via unit tests like a public method would be. This results in being able to test very little of the view model which opposes the supposed value of MVVM in concerns to testing and from a quality POV is disadvantageous as I have to rely on manual tests to prove the functionality of my code.
I might be wrong and am new to using MVVM but any help would be appreciated on how to go about this.
When I write WPF applications I focus my testing on the models.
I test view-models by calling commands and setting properties like the user would do by using the user interface. For trivial view models that just wrap a model one-to-one or call a service with 4 lines of code I don't write any initial tests.
As soon as I find something that doesn't work as expected when running the application I go back and write a test for that particular use case. That initial "bug" usually shows what was tricky to implement in that particular view model and is a good starting point to write more tests and continue development in a more test driven fashion.
You can test the same things that the user can do on your UI.
By definition those things will be public, since the view will binding to them.
eg. Say you have a Widgets collection, and an AddWidgetCommand. You can test that executing the command will add a widget to the collection.
There is need to create small scale winform applications for private use by my company for interaction with our database. Period. I know that .NET MVC has a very mature unit testing framework for the MVC pattern as I want to do TDD.
Thus, is it possible to use NUnit or some other easy/mature unit testing framework (EDIT: Based on my experience with ASP.NET) with the following tutorial given here? I have googled and checked my technical book library, and there is a distinct lack of documentation for how to do effective unit testing for winforms. Thus, I am turning to this forum hoping individuals can share their domain knowledge with me.
The most I have found has recommended the MVC pattern (which I agree with), but not how to address specific issues with the winform. For example, how do I test a button click and subsequent action by that button?
I plan on using C# VS13 .NET 4.5. I am excited to join this resource and will contribute rep to all who answer my inquiry. Thanks.
As you have probably noticed, the idea there is to have your view described with an interface.
Thus, the controller doesn't really need a window, it needs a class implementing the interface.
And thus, you could have yet another, auto-mocked or manual implementation of the view interface that doesn't involve the WinForms subsystem but rather, exposes the data to write your assertios.
Having your stub view, you just write a script against it. You expose some methods from the class that allow you to automate the interaction:
public class ViewStub : IView
{
// implement the view interface as it is but also
// an extra stuff to let you automate this in your unit tests
public void RaiseButtonClick()
{
this.controller.DoTheButtonClickStuff();
}
}
Then your test becomes (I follow the convention from the tutorial)
ViewStub form = new ViewStub();
IModel mdl = new IncModel();
IController cnt = new IncController(view,mdl);
form.RaiseButtonClick();
Unit Testing a GUI is something that is independent of the GUI library used. The answer to the general case answers your case as well:
How can I unit test a GUI?
Unit testing a GUI is done by minimizing the footprint of classes that do depend on your GUI framework. Then the classes that still depend on the GUI framework are not unit tested (which is not at all the same as "are not tested"). Those classes are the "View" in patterns like MVP, MVC, MVVM.
Conclusion: Every good .Net Unit Testing framework is a good WinForms Unit Testing framework. One example of such a framework is NUnit, which you mentioned in your question.
Unit testing is not inteded for UI. Of course you can do it, but I don' recommend it for few reasons: You cannot unit test DPI changes, multiple screen, how your program acts in different window states or what happens if user moves with tabulator between your controls. Unit testing UI will only give you false safety.
Use UI automation tools to test UI automatically if you want to, but leave the unit testing out of it. You can keep the UI layer thin as possible and this is also a good design practice. You can use unit testing for other classes which are used in your winforms app.
I'm not probably first who deals with mocking in windows store application for testing purpose. I would like to test my ViewModels and to use some of mocking frameworks to mock them. Of course, all of available (common) frameworks are not able to use in windows store application project. I have one idea how to solve it but I'm not sure that it is best solution. My solution consists of these projects. Main point is to divide presentation layer to two parts :
Presentation - Windows store application
Start-up project that contains only presentation views (Pages) and presentation parts that do not need to be tested. This project has reference to PresentationLogic.
PresentationLogic - Portable Class Library, Targets : Windows store application, .NET Framework 4.5
This project contains all presentation logic like ViewModels, Converters, Helpers etc. that should be tested
UnitTests - Class library
Classical class library containing unit tests with ability to mocking all interfaces from PresentationLogic. This library has reference to PresentationLogic.
It is quite strange to divide Views and ViewModel to two layers but I did not find another solution for this.
Do you have please any idea how to deal with this problem? What about splitting of the presentation layer to the two layers of another project type? Can it cause some problems in further development?
You're definitely on the right track. A couple of notes:
Using MvvmLight (which is available portable, by the way), you can use their built-in ServiceLocator and DependencyInjection to do things like inject test controllers for platform specific processes. This will allow a ton of your logic to remain portable, by defining interfaces and injecting the implementations (including mocked implementations).
Based on your PCL, you will likely (in my experience) be unable to include Converters (which inherit from IValueConverter) in your PCL. The library is generally different between the platforms (especially Silverlight/WinRT/4.5/Mono), as the most common use for them is for UI, such as binding processing. Same with things like DataTemplateSelectors. These will likely have to be rewritten for most of your platforms (though luckily that's not that hard and is still quite a bit of copy-paste).
As to the rest of it, you have it spot on. You can have your Presentation app be Universal, so it can cover both Windows Store and Windows Phone Store apps. The vast majority of your 'business logic' should be in your PCL. You may run into some issues in this regard because sometimes it's just unavoidable to want to put some UI helpers inside the VM for ease of use. If this is absolutely necessary, you can make your Portable ViewModel abstract, then use the Dependency Injection mentioned above to insert the platform-specific implementations. It's quite easy to do and very useful.
The one thing that you are missing is UI tests. You could include them in your unit test class library, or make another Coded UI Test class library, up to you.
Anyway, hope that helps.
FYI, you can now use JustMock in order to mock directly into Windows 8.1 Unit Test projects.
See my answer
I am wishing to teach myself how to effectively test using VS2010 and C# for an upcoming interview. Any resources on learning this would be greatly appreciated (especially a quick and dirty "here is how you create a test project/run it/make assertions" document - I just need to get my hands dirty!). :)
What I am trying to learn with is a small project which I have written. I have a few comboboxes with criteria/keywords which queries certain columns in a table to see if the right values are returned. So, for instance, I have a column "Colour" and a corresponding combo box in my WPF application for "Colour". When "Red" is selected, I want to return all the cols with the "Red" value in its row etc. etc.
I've randomised my db data and want to create some assertions now (eg for "Red" combobox value, "Red" rows only are returned).
What is the most effective and best way I can test an application of this nature?
Theoretically, I know it's about creating some test data, feeding "Red" into the search function and asserting that only "Red" columns are returned. However, practically, how do I do this with VS2010 and C#? Resources for this are, surprisingly, hard to come by.
Do I open the project, add a new test project, create a standalone project, where do I go from there...? A simple beginners intro to adding a test project and some guidelines for the best ways to make assertions would really help me out.
Thanks very much.
Please have a look a the MVVM-Pattern, that allows you to create modular and testable WPF-applications. In the referenced Wikipedia article you will find lots of resources for further reading.
If you want a UI testing framework for WPF, see How to test a WPF user interface?.
If you want to test your underlying logic, create a class structure that represents your UI (commonly called a View Model), move it to a separate class library assembly (DLL) and test it using testing library like MS Test or NUnit. Reference the view model from the application.
To test WPF Application with Unit tests you need to implement MVVM Pattern.
Then, right click on a method you want to test, and select Create Unit tests