So I've got this nice little MVVM solution, and things work great. I've got a view model for a header bar that adjusts the icon based on the state of the application, etc. I've done acceptance tests, the view model works great.
So I want to unit test the behavior of this view model. I create my unit testing project, add a new unit test for the view model, and write a simple smoke test. (i.e. Given mocked dependencies, will the class instantiate).
Bam, no
However, the class works fine when ran normally. Upon further inspection, my error is as follows:
TestInitialize threw exception: System.UriFormatException: Invalid URI: Invalid port specified.
So following the call stack I arrive at the conclusion that my pack URLs used to load resource streams are the ones kicking the errors.
pack://application:,,,/Operations.Shell;component/Media/Images/User_Normal.png
(Note: Operations.Shell
is the assembly name, /Media/Images/User_Normal.png
is the image path/name, and this pack url works in practice.)
Is the pack url I have for my User_Normal.png, the file exists, the resource is properly packed into the assembly (checked with reflector).
The problem arises from the System.Uri
class not being able to interpret the pack url. This is where I'm getting lost. Why would this not work in the confines of testing. I have all the WPF Assemblies referenced in my test project:
What am I missing?
Update
Alright so the original problem was that the UriHandler wasn't registered for pack urls. (Thanks to Julien Lebosquain) Now that that's fixed it's still having issues.
TestInitialize threw exception: System.NotSupportedException: The URI prefix is not recognized.
System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase) System.Net.WebRequest.Create(Uri requestUri) MS.Internal.WpfWebRequestHelper.CreateRequest(Uri uri) System.IO.Packaging.PackWebRequest.GetRequest(Boolean allowPseudoRequest) System.IO.Packaging.PackWebRequest.GetResponse() MS.Internal.WpfWebRequestHelper.GetResponse(WebRequest request) System.Windows.Media.Imaging.BitmapDecoder.SetupDecoderFromUriOrStream(Uri uri, Stream stream, BitmapCacheOption cacheOption, Guid& clsId, Boolean& isOriginalWritable, Stream& uriStream, UnmanagedMemoryStream& unmanagedMemoryStream, SafeFileHandle& safeFilehandle) System.Windows.Media.Imaging.BitmapDecoder.CreateFromUriOrStream(Uri baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption, RequestCachePolicy uriCachePolicy, Boolean insertInDecoderCache) System.Windows.Media.Imaging.BitmapImage.FinalizeCreation() System.Windows.Media.Imaging.BitmapImage.EndInit() System.Windows.Media.Imaging.BitmapImage..ctor(Uri uriSource, RequestCachePolicy uriCachePolicy) System.Windows.Media.Imaging.BitmapImage..ctor(Uri uriSource) MyFramework.Resources.b__1(Uri u) MyFramework.Resources.ResourceType`1.Load(String path) Operations.Shell.AppShell.ViewModels.HeaderViewModel..ctor(IEventAggregator eventAggregator, ISecurityService securityService) Tests.Shell.AppShell.TestHeaderViewModel.TestInitialize()
It looks like the pack url's trying to resolve to something web-based for an assembly pack url? Looks like the handler's routing the request wrong? Or am I missing something?
Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. This testing methodology is done during the development process by the software developers and sometimes QA staff.
Generally, unit tests are written by the developers in order to find bugs in their code. In some cases the developer will write a unit test and it will help him to find the bug immediately. In other cases, all the unit tests will pass and the code would be bug-free.
Unit testing may not be possible in all situations. When object-oriented software is considered, the concept of unit testing changes. Encapsulation drives the definition of classes and objects. This means that each class and each instance of a class packages attributes and the operations that manipulate these data.
I got bitten by this problem once too...
Referencing the assemblies isn't enough. WPF needs to call System.UriParser.Register()
with its own URI parser so that System.Uri
can interpret pack URLs.
Reflecting tells us that this is done by the static constructor of System.IO.Packaging.PackUriHelper
. Call any method of this class in your test, like PackUriHelper.Create()
to ensure the URI parser is well registered. Kind of ugly, but should work.
Building on other answers, here's the (NUnit) code that made my tests go green:
In AssemblyInfo.cs:
[assembly: RequiresSTA]
In its own file:
[SetUpFixture]
public class PreTestSetup
{
[SetUp]
public void Setup()
{
PackUriHelper.Create(new Uri("reliable://0"));
new FrameworkElement();
System.Windows.Application.ResourceAssembly = typeof (App).Assembly;
}
}
App is my main application class. Any class in the relevant assembly will do, presumably.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With