Windows Store App Unit Testing a USB device - unit-testing

I'm writing a USB device API for Windows Store Apps that uses Windows.Devices.USB API from Windows 8.1 to connect and communicate with the custom USB device. I'm using the Visual Studio 2013 dev preview IDE.
The following function in the library is used to connect to the USB device.
(Simplified for clarity)
public static async Task<string> ConnectUSB()
{
string deviceId = string.Empty;
string result = UsbDevice.GetDeviceSelector(new Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"));
var myDevices = await Windows.Devices.Enumeration.DeviceInformation.FindAllAsync(result, null);
if (myDevices.Count > 0)
{
deviceId = myDevices[0].Id;
}
UsbDevice usbDevice = null;
try
{
usbDevice = await UsbDevice.FromIdAsync(deviceId);
}
catch (Exception)
{
throw;
}
if (usbDevice != null)
return "Connected";
return string.Empty;
}
When called from the Windows Store App project, this function connects to the device flawlessly. However, when called from the Unit Test Library for Windows Store Apps project, the statement in the try block throws an exception.
A method was called at an unexpected time. (Exception from HRESULT: 0x8000000E)
from what I've looked around, this happens when an Async function is called without the await keyword. But I'm using the await keyword alright!
Some more info, I am unable to use NUnit to write unit tests for Store Apps so am using the MSTest Framework.
[TestClass]
public class UnitTest1
{
[TestMethod]
public async Task TestMethod1()
{
await ConnectToUSB.ConnectUSB();
}
}
Also, I've included the following capability tags in the manifest files of both the App store projects too without which it's impossible for the Store Apps to connect to devices.
<m2:DeviceCapability Name="usb">
<m2:Device Id="vidpid:ZZZZ XXXX">
<m2:Function Type="name:vendorSpecific" />
</m2:Device>
</m2:DeviceCapability>
Is there something I'm missing or is this a bug in the MSTest Framework?

I think the problem is that
await UsbDevice.FromIdAsync(deviceId);
must be called on the UI thread because the app has to ask the user for access.
You have to CoreDispatcher.RunAsync to ensure you're on the UI thread or actually be in the code behind for a page.

I had the same problem with Unit Test App (Universal Windows) in VS 2017.
I verify answer of my predecessor Greg Gorman(see below). And I found this is true.
If you uses inside method body this construct:
Windows.ApplicationModel.Core.CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(
Windows.UI.Core.CoreDispatcherPriority.Normal,
async () =>
{
...
UsbDevice usbDevice = await UsbDevice.FromIdAsync(deviceId);
...
}).AsTask().Wait();
the FromIDAsync will work as you expect.
For your example change the test method to this:
[TestClass]
public class UnitTest1
{
[TestMethod]
public async Task TestMethod1()
{
Windows.ApplicationModel.Core.CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(
Windows.UI.Core.CoreDispatcherPriority.Normal,
async () =>
{
await ConnectToUSB.ConnectUSB();
}).AsTask().Wait();
}
}

Related

Unit tests for ASP.NET Core failing in VSTS pipeline due to HttpStatusCode.TemporaryRedirect

I have an ASP.NET Core 2.2 WebAPI that uses xUnit and FluentAssertions frameworks. It creates a Microsoft.AspNetCore.TestHost.TestServer and from that server object we create an HttpClient using Microsoft.AspNetCore.TestHost.TestServer.CreateClient() API.
The unit tests work great on my local Windows 10 machine using Visual Studio 2017 Pro. I committed the code, then did a pull request. The pull request automatically kicks off a build process to ensure it builds. Once it builds, it looks for then runs the unit tests. At this point it fails. I have 242 unit tests. All 242 unit test fail with the exact same error reported by the agent:
Expected resp.StatusCode to be OK, but found TemporaryRedirect.
All 242 unit tests make a request to the test server, so they all expect an HttpStatusCode.OK (or similarly expected) response. I should never expect a HttpStatuscode.TemporaryRedirect so I really don't want to add a test case for this.
The build server is running in VSTS as Microsoft Server 2012 R2 with Visual Studio 2017 Pro installed.
Why would the TestServer object return a Redirect ever?
If there is no way around this, can I force the HttpClient to auto-redirect when it receives this status so I only get the result of the API call?
Here is the code I am using to create the server and the client:
var config = new ConfigurationBuilder()
.SetBasePath(Path.GetFullPath("../../../../XXXXXXXXService/"))
.AddJsonFile("appsettings.json", optional: false)
.Build();
_server = new TestServer(new WebHostBuilder().UseStartup<Startup>().UseConfiguration(config));
TestHttpClient = _server.CreateClient();
An example unit test that is failing:
private string DeriveHttpPath(string path) =>
$"/{_rootPath.Trim('/')}/{path.TrimStart('/')}";
private static async Task<TResult> ValidateAndReadResponseAsync<TResult>(
HttpResponseMessage resp, HttpStatusCode statusShouldBe, Func<TResult> defFactory = null)
{
(resp.IsSuccessStatusCode ? HttpStatusCode.OK : resp.StatusCode).Should().Be(statusShouldBe);
try
{
return await resp.Content.ReadAsAsync<TResult>();
}
catch (Exception ex)
{
return defFactory != null ? defFactory.Invoke() : throw ex;
}
}
public async Task<TResult> GetDocumentDataAsync<TResult>(string documentId,
string path = null, HttpStatusCode statusShouldBe = HttpStatusCode.OK)
{
using (var msg = new HttpRequestMessage(HttpMethod.Get,
DeriveHttpPath($"{_collectionId}/{documentId}?path={path}")))
using (var resp = await _httpClient.SendAsync(msg))
{
return await ValidateAndReadResponseAsync<TResult>(resp, statusShouldBe);
}
}
_rootPath will be the root of the controller, i.e.: /api/MyController
Thank you for any help.
The issue I was having was because this was defined in the startup.cs:
#if !DEBUG
app.UseHttpsRedirection();
#endif
So when I was running the unit tests locally, it was compiled as Debug, where when it was pushed to the build server, it compiled as Release and the Https-Redirection was turned on.
I took that code out and made my WebAPI HTTPS-Only by setting it in Azure.

ASP.NET Web API Unit Test Autofac Module with BuildManager.GetReferencedAssemblies()

Working on a project in ASP.NET Web API 2 which has Autofac as my IoC container. This project is hosted on IIS and in my Autofac module I use the following method to scan for assemblies:
var asm = BuildManager.GetReferencedAssemblies().Cast<Assembly>().ToArray();
Why?
https://docs.autofac.org/en/latest/register/scanning.html#iis-hosted-web-applications
But now we are making Unit Tests using NUnit, during my setup I register my module which uses this method. Now I receive the following exception when running my tests:
System.InvalidOperationException: 'This method cannot be called during the application's pre-start initialization phase.'
I understand why I have this exception but I don't have a clue how to make my code work in tests and for deployment environments.
Setup method of NUnit:
[TestFixture]
public abstract class ApplicationTestBase
{
[SetUp]
public override void Init()
{
var builder = new ContainerBuilder();
// If the class requires auto mapper mapping, initialize them
// We do this in order not to init them for every test => optimalisation!
if (GetType().GetCustomAttributes<RequiresAutoMapperMappingsAttribute>(false) != null)
{
builder.RegisterModule<AutoMapperModule>();
}
this.Container = builder.Build();
}
}
Do I need to create a new module specific for my Unit tests or is there another way for this?
AutoMapperTest
[RequiresAutoMapperMappings]
[TestFixture]
public class AutoMapperTests : ApplicationTestBase
{
[Test]
public void Assert_Valid_Mappings()
{
Mapper.AssertConfigurationIsValid();
}
}
UPDATE
Like Cyril mentioned: Why do you need Ioc in your unit tests? I went searching and indeed you don't have to use the Ioc in your tests. So I ditched the Ioc and initialized my mapper configuration byy doing:
Mapper.Initialize(configuration =>
{
var asm = AppDomain.CurrentDomain.GetAssemblies()
.Where(a => a.FullName.StartsWith("ProjectWebService."));
configuration.AddProfiles(asm);
});
I would recommend separating the "how to load assemblies" logic from the "do assembly scanning and register modules logic."
Right now I'm guessing you have something like this all in one method.
public IContainer BuildContainer()
{
var asm = BuildManager.GetReferencedAssemblies().Cast<Assembly>().ToArray();
var builder = new ContainerBuilder();
builder.RegisterAssemblyTypes(asm);
var container = builder.Build();
}
Not exactly that, but something similar - the loading of assemblies is inlined and directly used.
Separate that so you can swap that logic in for testing. For example, consider allowing a parameter to be optionally passed so you can override the logic in test.
public IContainer BuildContainer(Func<IEnumerable<Assembly>> assemblyLoader = null)
{
IEnumerable<Assembly> asm = null;
if (assemblyLoader != null)
{
asm = assemblyLoader();
}
else
{
asm = BuildManager.GetReferencedAssemblies().Cast<Assembly>().ToArray();
}
var builder = new ContainerBuilder();
builder.RegisterAssemblyTypes(asm);
var container = builder.Build();
}
Your default logic will work the way you want, but then in testing you can swap in something else.
var container = BuildContainer(() => AppDomain.GetAssemblies());
There are lots of ways you can do that swap-in. It could be anything from a static property you can set somewhere to a virtual method you can override somewhere. The point is, by separating the assembly loading logic you can get the test-time behavior to work but still use the registration behavior you're after.

What is a good practice to write unit-test on .net core Ihostedservice?

I have a background task initiated in .net core 2.0 startup, inherits from backgroundservice, implementing StartAsync, StopAsync and ExecuteAsync. This task is to update some data in database table periodically based on some business logic.
While I can run the backgroundtask as an application and test using logs, db check and with the help of other tools, can the unit-testing is necessary for testing the backgroundtask? If so how to register the task as a service with dependencies and trigger the start and stop methods to assert the actual vs expected? Appreciate some basic sample unit-test method on testing timer based .net core ihostedservice backgroundtask.
Here is my basic test start just for sample, but not completed yet. Having said that, this is just a thought but not the exact working test. Here is what need some help from the community. Can also add some more asserts i.e. Assert.Verify()?
[Fact]
public async void Run_background_task_success()
{
//Arrange
IServiceCollection services = new ServiceCollection();
services.AddHostedService<BackgroundManagerTask>();
var serviceProvider = services.BuildServiceProvider();
var service = serviceProvider.GetService<IHostedService>() as BackgroundManagerTask;
var isExecuted = false;
if(await service.StartAsync(CancellationToken.None))
{
isExecuted = true;
}
await Task.Delay(10000);
Assert.True(isExecuted);
await service.StopAsync(CancellationToken.None);
}
Here's how I usually do it. You mention you are going to the database to update some data, so I'm assuming you are expecting that as a dependency from BackgroundManager
[Fact]
public void BackgroundManagerUpdatingDataTest()
{
// Arrange
Mock<IDataAccess> dbMock = new Mock<IDataAccess>();
dbMock.Setup(x => x.UpdateSomethingInDB(It.IsAny<BusinessObject>())).Returns(1); // One row updated from the DML in UpdateSomethingInDB from the BusinessObject
BackgroundManager sut = new BackgroundManager(dbMock.Object); // System under test.
// Act
await sut.StartAsync(CancellationToken.None);
await Task.Delay(500); // Give the test some time to execute.
await sut.StopAsync(CancellationToken.None); // Stop the Background Service.
// Assert
dbMock.Verify(x => x.UpdateSomethingInDB(It.IsAny<BusinessObject>()), Times.Exactly(1));
}
Above, we are plainly testing the update to the database occurred by Mocking the data access call and verifying that it was called exactly once.
You could of course Mock any other dependency out using Moq and Assert on anything else you want to verify.

Searching for nicer implementation for this unit test

I use xUnit and FluentAssertions to write my unit tests and I am stuck at the following problem. As I have not implemented the catch (in GetCountriesAsync) of the WebException yet, I throw a new NotImplementedException in this place.
This code is the only way I made the test actually work as expected. I added the native xUnit implementation either, due to FluentAssertions is just syntactic sugar.
[Fact]
public async Task GetCountriesAsyncThrowsExceptionWithoutInternetConnection()
{
// Arrange
Helpers.Disconnect(); // simulates network disconnect
var provider = new CountryProvider();
try
{
// Act
var countries = await provider.GetCountriesAsync();
}
catch (Exception e)
{
// Assert FluentAssertions
e.Should().BeOfType<NotImplementedException>();
// Assert XUnit
Assert.IsType<NotImplementedException>(e);
}
}
Though I found this implementation a lot nicer, it just doesn't work.
[Fact]
public async Task GetCountriesAsyncThrowsExceptionWithoutInternetConnection3()
{
// Arrange
Helpers.Disconnect(); // simulates network disconnect
var provider = new CountryProvider();
// Act / Assert FluentAssertions
provider.Invoking(async p => await p.GetCountriesAsync())
.ShouldThrow<NotImplementedException>();
// Act / Assert XUnit
Assert.Throws<NotImplementedException>(async () => await provider.GetCountriesAsync());
}
As VS2012/ReSharper already suggests to remove the redundant async keyword of the test method, I replaced async Task with void and the test still behaves the same, so I suspect the async Actions cannot be awaited, they're rather fired and forgotten.
Is there a way to implement this properly with xUnit/FluentAssertions? I think I have to go with my first implementation as I can't see any functionality like InvokingAsync().
Actually, FA 2.0 has specific support for handling asynchronous exceptions. Just look at the unit tests in AsyncFunctionExceptionAssertionSpecs. for various examples.
Regarding FluentAssertions, I've added the following to my code:
using System;
using System.Threading.Tasks;
namespace FluentAssertions
{
public static class FluentInvocationAssertionExtensions
{
public static Func<Task> Awaiting<T>(this T subject, Func<T, Task> action)
{
return () => action(subject);
}
}
}
and now you can do:
_testee.Awaiting(async x => await x.Wait<Foo>(TimeSpan.Zero))
.ShouldThrow<BarException>();
whereas _teste.Wait<T> returns a Task<T>.
Also the naming of the method Awaiting make sense, because pure invocation of the method will not result in the exception being caught by the caller, you do need to use await to do so.

Unit Tests Not Appearing

I'm using Visual Studio Express 2012 on the Windows 8 Release Preview and I can't seem to get my unit tests to appear in the test explorer.
I have a class called TestApp.Entity, and TestApp.EntityTest...
Here is my code:
namespace TestApp.Entity.Test
{
using System;
using System.Net.Http;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;
using TestApp.Domain;
[TestClass]
public class EntityTests
{
[TestMethod]
public async void TestObject1Deserialize()
{
Uri agencyUri = new Uri("*removed*");
HttpClient httpClient = new HttpClient();
HttpResponseMessage response = await httpClient.GetAsync(agencyUri);
string responseBodyAsText = await response.Content.ReadAsStringAsync();
List<Agency> agencyList = Deserializers.AgencyDeserialize(responseBodyAsText);
CollectionAssert.Contains(agencyList, new Agency() { Tag = "*removed*", Title = "*removed*", ShortTitle = "", RegionTitle = "*removed*" });
}
}
}
I assume that's all I needed to do, but they still don't appear in the test explorer. Any advice would be helpful.
As per Stephen Cleary, "you need to make your unit tests async Task instead of async void for them to work correctly".
This fixed the problem and the tests appeared. It's odd that no errors appeared when I used void, but now I know. Thank you!
I have Visual Studio 2012 and i couldn't see the Tests in Test Explorer,
So I installed the following: NUnit Test Adapter
That fixed the issue for me !
Do a rebuild all on the application, including any projects that contain test classes and test methods. They should appear in Test Explorer soon after.