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
Related
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.
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.
I've read MEF documentation on Codeplex and I'm trying to figure out how to accomplish my task:
I would like to build an application framework that has standard components that can be used to do some common work (like displaying a list of records from a database). Plugins should be reused many times with different configuration each time. (eg. I have 5 windows in an application where I display record lists, each with different type of entity, different columns, each one should have it's own extension points like for displaying record details that should be satisfied with a different copy of another common plugin).
Is MEF suitable for such a scenario? How should I define contracts? Should I use metadata? Can I define relationships using configuration files?
Yes, you can use MEF. MEF supports NonShared instantiation of objects using the PartCreationPolicy attribute:
[PartCreationPolicy(CreationPolicy.NonShared)]
More information on this here.
Personally I'd do the wiring and configuration after the importing of the component on the target. However I am not sure how generic you want your application to be, if you are making a 'framework' to do certain solutions in I can imagine you want the configuration to be separate. You can go all-over-board and make an ISuperDuperGridConfiguration and import these on the constructor [ImportingConstructor] of your grid plugin. From within your target (where the grids get imported) set the location of the grid to the grid plugin (like main grid, side grid) and use the data stored in ISuperDuperGridConfiguration to further config the grid plugin itself.
However, you can easily go 'too far' with MEF, depending on your goals. We have a completely MEF componentized UI for an application with customized needs for every single customer. Sometimes I have the urge to put single buttons from the ribbon in a MEF extension.
As you can see, depending on your needs, you can and sometimes will go too far.
I don't think you'd need metadata especially in your case, but maybe someone else can share a different opinion on this ;-).
I hope this answers your question, if not please comment so I can highlight more aspects. All in all using MEF has been very positive for us, and we are using it far beyond a 'hello world' so to say. So at least you have that!
I'm trying to improve the automated testing in my application, but am unsure of the best way to proceed.
My app gathers data from multiple forms, recodes it and stores it in a database. I have created a pretty complex SQL view, which flattens the structure out, so it can be imported into a stats package (SPSS).
My concern is that the view is complex, and I want to automate some tests around it.
Currently I have some functional tests, which create a complete form objects model, and sends it into the application. I then retrieve the view from the database, and use reflection to test that the retrieved view fields match the original data.
The problem is that this is very manual and heavy, my fixtures are lengthy, and it is cumbersome to add new scenarios (i.e. various parts of the model incomplete).
Does anyone have any advice on how I could improve my test strategy? Tips tricks all welcome!
Thanks!
DbFit is perfect for this. DbFit is an extension of FitNesse which maybe you are already using since you spoke of using "fixtures". In any case, DbFit makes it really easy to set up a test where you can seed some data, run the View, compare the expected results, and then it will automatically rollback the data that you just seeded for the test. And it is very easy to update as you add more fields to the View. AND it requires no additional objects in your DB like some other SQL "unit" testing suites.
You can find more info on using DbFit at:
http://benilovj.github.com/dbfit
http://groups.google.com/group/dbfit
And here is a tutorial that I wrote for it that explains the basic options:
http://www.sqlservercentral.com/articles/Testing/64636/
This is a very difficult question to answer. It almost sounds to me like You want to make a single test that tests all in one go.
First, Your app should be constructed, so each functionality is isolated in its own class, thereby making it easy to test AND easy to replace by stubs when testing other things. Dependencies on other functions should be injected (Dependency Injection).
Second, you should use the same technique for external systems like database connections and SPSS file writers. This involves wrapping such functionality so these dependencies also can be injected, and thus replaced by stubs when testing other aspects of your app.
Third, be aware that if tests are hard to write, 99,99% of the time this indicates that your design is not as strong as it could be.
Regards,
Morten
I've written a simple desktop application with C#/WPF and I'm now looking to create another, larger application which will share much of the functionality. I'm thinking that I should create three separate projects: one containing the shared code, and one each for the two apps.
My problem is that I'm not entirely familiar with .NET/WPF so I don't know if there are some best practices for this sort of thing. Can anyone offer some good sources of information, example projects or just some brief advice?
Edit: To put a little more detail on the scenario, the first application is a specialised editor and the second application is taking this file editor and wrapping a project model around it to create a sort of basic IDE.
Honestly it depends on what level the code you intend to share is. For instance, it's entirely plausable to put all of your business logic code into one project/class library and maintain it independantly, but mixing biz logic with WPF custom controls should be STRONGLY discouraged. Think about the layers of abstraction you are modularizing, and the dependancy heiarchy you are introducing and refactor accordingly.
Edit:
In response to your above changes I suggest the following: The logic and DAL associated with the above should be pushed into a project as seperate namespaces. The visual elements (the view, viewmodel) should most likely be moved into a seperate project and namespace set as well. Once you can merge these together and launch them from an exe that contains a host window and a UserControl for the rest of your hosted visual content, you can then probably move forward with integration into your larger IDE project. The key here is:
Visual Layer and View Logic -> Editor.Visual.dll
Biz Logic & Data Access -> Editor.Core.dll
I hope this helps.