I would like to create a headless test library for unittesting my Universal Windows Platform App. I know that Visual Studio offers a test app, but this comes with a head and executable, rather than a headless library.
Even XUnit says to create this test app which again has a head to it.
http://xunit.github.io/docs/getting-started-uwp.html
The only alternative I have found is to use a PCL To expose some of the functionality to a standard test class, but this is really non-ideal as it limits what I can test to be non-uwp functionality.
Any recommendations?
Comparing with the desktop app, the Windows Runtime App was running on the app container (an isolated process with low integrity).
The unit-test for UWP app is running on a blank UWP App (to ensure the test library is also running on the app container). Since the traditional test loader is running on a normal process, I’m afraid we cannot create a headless unit-test library for UWP app which can run on a normal process.
I had a similar challenge. While I was unable to test headlessly, what I did was to separate out the business logic from classes that refenced uwp classes (e.g. Windows.). I ensured that the business logic contained only C# standard classes (sometimes, i did have to to map some classes to more common dotnet core classes, like using a Hashtable for my resources instead of Windows.ApplicationModel.Resources). The Hashtable became my interface for passing resources around, and I have one (admittedly untested) class that maps them back and forth.
Once I did that, i created a regular headless dotnet core unit test using Microsoft.VisualStudio.TestTools.UnitTesting.
The unit test project file has all the classes i wanted to test (as links) as well as the unit tests themselves. By doing things this way, I'm able to test all the business logic. The only thing that does NOT get tested is the UWP-specific stuff (In my case its just gui code, and a few mapping classes). You can use a variety of techniques (abstract interfaces/MVVM/delegates, etc) to ensure the callback to your GUI gets CALLED, you just can't test that very upper layer.
Its not perfect, but it does provide for testing a significant portion of your app. If you have the GUI just for display, and put all the logic into a class that CAN be tested, it will make for a very small amount of code that is not tested.
Related
Every time, when I deal with writing Tests in .NET (C#), I read, you can test DLLs only. But my app hasn't any DLLs and I want test some controllers and behaviours too. How it is possible, without creating an DLL project? Is it possible?
Hints are welcome.
Your unit test project(s) can still reference application projects like any other class library. It may be considered less ideal, but there's nothing preventing it from working. As the logic of your system grows, even a little bit, you'll certainly want to consider moving the business logic into Class Library projects and keeping the application layer as thin as possible.
I read, you can test DLLs only.
This was an oversimplification. What they probably meant was that you can test discrete functionality only. Regardless of what kind of project is hosting that functionality, the functionality itself has to be well defined, with separated concerns, and individually testable. If that's causing a problem in your design, then you have more work to do in order to unit test your code.
But to get started, simply create your unit test project and reference your other project. Then start writing tests for your individual units of functionality. Each test should be testing only one discrete thing, and should consist of the simple steps of:
Arrange
Act
Assert
Unit tests shouldn't require any additional setup, nor should they produce any side effects. This is where the "discrete" part comes in, each one should be individual and not depend on others.
I'm new at web development (used to develop desktop apps). I didn't manage to find a proper way to unit test internals of my web application.
Let's say I do have a Foo class which do have a strictly defined behaviour (completely independed from DB and/or UI). I need to make sure that my implementation is corrent. In the desktop app I just add another test dll with unit tests (if the class is public) or just internal class with tests. And start it with nunit to make sure that it works. But how is should be done in the web application?
The only way I can think of is to add some debug-only pages on which I will run my test and ignore them during the deploy. But I think there should be some unit test framework for that and I just didn't manage to find it.
Do the .net core web developers have any standard way to do it (something like nunit)?
Yes, the recommended unit testing framework to use with .NET Core apps is called Xunit. You can read an overview and walkthrough here.
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'm working with this small web application (1 page) built by someone else that does a specific task after pressing a button on the web page.
Now the requirements have changed slightly, and we need to automate this to run weekly without the need of user interaction.
What would be the best way of doing this, minimizing the changes done to the code?
I was thinking on adding a console app to the project that then references internally the web app but that doesnt seem to work.
Or maybe converting the web app to a to console app, if that is actualy possible?
Is there any straightforward way of doing this?
Thanks
First, make sure the "specific task" is broken out from the Web application so it resides in its own .NET project. Even if this project just contains one class you're "separating concerns" between the Web-based UI and the task itself.
Then you can create another "wrapper project" to call this new project as you wish. A console application might well do the job -- you can run that using a Scheduled Task -- or you may prefer to use a Windows service.
It really depends on how well the existing code is structured. A common approach is to divide business logic from the presentation layer. In VS, it's normally done by creating a class library project and keeping all the business logic in there. A web application project would then just instantiate business logic classes and run their methods.
If it is done like that, you just need to reference the class library project. If, on the other hand, you have all the logic in the web application project, probably there's no fast way of doing that, as you're not supposed to instantiate Page classes manually (well, you can do that as well, but that is clumsy and not recommended).
So in that case, you should create a class library project and move there all the logic you need to use in your console app. I would imagine that would require quite a bit of refactoring.
I am currently programming a ASP.NET MVC3 application, using Entity Framework 4.
There are certain tasks (processing 10K+ of records, for instance) that has to run in the background. I am writing a console application to do the job (and maybe run it as a thread or window service).
Both the console app and MVC3 EF4 project
Since I have written lots of services and model code inside the MVC3 application, I would like to reuse that in my console project.
Is that possible?
(Due to time constraint, I cannot refactor our the services into another DLL/code library)
Moving the services and model code into another DLL shouldn't take more than about 10 minutes, if that. You don't even need to change the namespaces if you don't want to - just create the new project, move the files over, add a reference to the class library from both the console project and the MVC project, and you should be done.
It depends on how you have built the MVC system and which parts you are going to use in your console application.
Eg If you are going to reuse Controller logic in your console app you need to provide fake implementations of numerous classes. Eg HttpContextBase.
Further more if you have use Session, Cache, HttpContext you will have hard time using the code base for the console app.