So I'm upgrading a bunch of our APIs and migrating them to the new shiny top-level statement style of startup.
These projects all also have integration tests that rely upon a WebApplicationFactory to create a TestClient for them. For the most-part, retargetting that at Program rather than Startup has worked just fine.
However, on one of my APIs, I just get 404s whenever I try to call a controller and I can't for the life of me work out why.
If I add in a minimal app.MapGet("test", () => "test") I can hit that from the test, so I guess for some reason, the controllers are getting unmapped. That being said, I'm struggling to see much difference between this API and the other ones.
So, all of my APIs follow the same basic pattern in Program:
var builder = WebApplication.CreateBuilder();
BuildConfiguration();
ConfigureLogging();
ConfigureXRay();
ConfigureServices();
ConfigureHost();
var app = builder.Build();
ConfigureApp();
app.Run();
I haven't included everything for brevity, but in ConfigureServices() I believe this line should add and configure all of the controllers:
void ConfigureServices()
{
builder.Services.ConfigureHealthChecks();
builder.Services.ConfigureAppMetrics();
builder.Services.ConfigureFromAppSettingsConfig(builder.Configuration);
builder.Services.ConfigureIOCServices(builder.Configuration);
builder.Services.AddAutoMapper(AppDomain.CurrentDomain.GetAssemblies());
builder.Services.AddControllers(opt => opt.AddGlobalErrorHandling()); //<----- This one
builder.Services.AddSoapCore();
builder.Services.ConfigureSwagger();
}
Then in ConfigureApp() I've got this call which I believe should map the controllers:
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
endpoints.UseSoapEndpoint<ICorporateActionsSoapService>("/investments/api/CorporateActions.asmx", new BasicHttpBinding());
});
So if I run the app directly, all of that seems to work. For my tests, I've got the following.
public class CustomWebApplicationFactory : WebApplicationFactory<Program>
{
public CustomWebApplicationFactory()
{
SetAppSettingsValues();
DisableMetricsBuiltFlag();
}
private void DisableMetricsBuiltFlag()
{
var metricsBuiltField = typeof(MetricsAspNetHostBuilderExtensions).GetField("_metricsBuilt",
BindingFlags.Static |
BindingFlags.NonPublic);
metricsBuiltField?.SetValue(null, false);
}
private void SetAppSettingsValues()
{
Environment.SetEnvironmentVariable("IntegrationTests", "true");
}
}
And then this is injected into my test classes as an IClassFixture<CustomWebApplicationFactory> by XUnit. I then replace a few of the services with mocks and create a test client.
public GlobalErrorHandlingIntegrationTest(CustomWebApplicationFactory factory)
{
_mockLogger = _fixture.Create<ILogger<CorporateActionsController>>();
_mockAuditService = _fixture.Create<ICorporateActionsEmailAuditService>();
_mockEmailService = _fixture.Create<ICorporateActionsEmailService>();
_mockEmailService.GetEmails().Returns(Task.Run(() => _fixture.Create<CorporateActionResponse>()));
_appFactory = factory
.WithWebHostBuilder
(
builder =>
{
builder.ConfigureTestServices
(
x =>
{
x.Add(new ServiceDescriptor(typeof(ILogger<CorporateActionsController>), _mockLogger));
x.Add(new ServiceDescriptor(typeof(ICorporateActionsEmailService), _mockEmailService));
x.Add(new ServiceDescriptor(typeof(ICorporateActionsEmailAuditService), _mockAuditService));
}
);
}
);
_testClient = _appFactory.CreateClient();
}
And then all of my tests using that _testClient just 404. Any idea what's going wrong here and why these controllers might be getting unmapped?
I've seen this question but the answer doesn't seem to apply to my case.
You have to pass the args to the WebApplication.CreateBuilder(args);
Related
I created several microservices using the ASP.net core API
One of these microservices returns the exact address of the other microservices
How to update the address of any of these microservices without restarting if the address is changed
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddHttpClient("MainMicroservice", x =>
{
x.BaseAddress = new Uri("http://mainmicroservice.com");
});
services.AddHttpClient("Microservice1", x =>
{
x.BaseAddress = new Uri("http://microservice1.com");
});
services.AddHttpClient("Microservice2", x =>
{
x.BaseAddress = new Uri("http://microservice2.com");
});
services.AddHttpClient("Microservice3", x =>
{
x.BaseAddress = new Uri("http://microservice3.com");
});
}
}
public class Test
{
private readonly IHttpClientFactory _client;
public Test(IHttpClientFactory client)
{
_client = client;
}
public async Task<string> Test()
{
var repeat = false;
do
{
try
{
return await _client
.CreateClient("Microservice1")
.GetStringAsync("Test")
.ConfigureAwait(false);
}
catch (HttpRequestException e) when (e.StatusCode == HttpStatusCode.NotFound)
{
var newAddress = await _client
.CreateClient("MainMicroservice")
.GetStringAsync("Microservice1")
.ConfigureAwait(false);
//todo change address of microservice1
repeat = true;
}
} while (repeat);
}
}
If you are building a microservice-based solution sooner or later (rather sooner) you will encounter a situation when one service needs to talk to another. In order to do this caller must know the exact location of a target microservice in a network, they operate in.
You must somehow provide an IP address and port where the target microservice listens for requests. You can do it using configuration files or environment variables, but this approach has some drawbacks and limitations.
First is that you have to maintain and properly deploy
configuration files for all your environments: local development,
test, pre-production, and production. Forgetting to update any of
these configurations when adding a new service or moving an existing
one to a different node will result in errors discovered at runtime.
Second, the more important issue is that it works only in a static
environment, meaning you cannot dynamically add/remove nodes,
therefore you won’t be able to dynamically scale your system. The
ability to scale and deploy given microservice autonomously is one
of the key advantages of microservice-based architecture, and we do
not want to lose this ability.
Therefore we need to introduce service discovery. Service discovery is a mechanism that allows services to find each other's network location. There are many possible implementations of this pattern.
We have two types of service discovery: client-side and server-side which you can find a good NuGet package to handle in ASP.NET projects.
I have two Restful APIs projects that am trying to merge in one application project ( new .net core one) I modified the code in Running multiple independent ASP.NET Core pipelines side by side in the same application to accept WebSockets as following the extension method looks like :
public static IApplicationBuilder UseBranchWithServices(
this IApplicationBuilder app,
PathString path,
Type requiredStartup) {
var webHost = WebHost.CreateDefaultBuilder()
.UseStartup(requiredStartup).Build();
var serviceProvider = webHost.Services;
var serverFeatures = webHost.ServerFeatures;
var appBuilderFactory =
serviceProvider.GetRequiredService<IApplicationBuilderFactory>();
var branchBuilder = appBuilderFactory.CreateBuilder(serverFeatures);
var factory = serviceProvider.GetRequiredService<IServiceScopeFactory>();
if (path.Value.Contains("/project2")) {
branchBuilder.Map(
"/project2/ws",
x =>
x.UseMiddleware<project2MicroService.WebSockets.WebSocketMiddleWare>(
serviceProvider.GetService<SceneWebSocketHandler>()));
} else if (path.Value.Contains("/project1")) {
branchBuilder.Map(
"/project1/ws",
x => x.UseMiddleware<project1Service.WebSockets.WebSocketMiddleWare>(
serviceProvider.GetService<project1WebSocketHandler>()));
}
var branchDelegate = branchBuilder.Build();
return app.Map(
path,
builder => {
builder.Use(
async (context, next) => {
if (!context.WebSockets.IsWebSocketRequest) {
await branchDelegate(context).ConfigureAwait(false);
} else {
await context.WebSockets.AcceptWebSocketAsync().ConfigureAwait(false);
await branchDelegate(context).ConfigureAwait(false);
}
});
});
}
and I call it in my new application for example like
app.UseBranchWithServices("/project2", typeof(project2MicroService.Startup));
while running unit tests the WebSocket connection is accepted but the middleware never been hit
any idea how to fix this, please , my unit test
[ClassInitialize]
public static void TestOneTimeSetUp(TestContext context) {
var webHostBuilder = WebHost.CreateDefaultBuilder();
webHostBuilder.UseContentRoot(Directory.GetCurrentDirectory());
webHostBuilder.UseStartup<Startup>();
server = new TestServer(webHostBuilder);
client = server.CreateWebSocketClient();
}
/// <summary>
/// OneTimeTearDown
/// </summary>
[ClassCleanup]
public static void TestOneTimeTeardown() {
server.Dispose();
}
/// <summary>
/// TestWebsocketCanBeCreated
/// </summary>
[TestMethod]
public void TestWebsocketCanBeCreated() {
var TEST1wsUri = new UriBuilder(server.BaseAddress + "project1/ws") { Scheme = "ws" }.Uri;
var TEST1websocket = client.ConnectAsync(TEST1wsUri, CancellationToken.None).Result;
var TEST2wsUri = new UriBuilder(server.BaseAddress + "project2/ws") { Scheme = "ws" }.Uri;
var TEST2websocket = client.ConnectAsync(TEST2wsUri, CancellationToken.None).Result;
Assert.AreEqual(WebSocketState.Open, TEST2websocket.State);
Assert.AreEqual(WebSocketState.Open, TEST1websocket.State);
Task.WaitAll(
TEST1websocket.CloseAsync(
WebSocketCloseStatus.NormalClosure,
"",
CancellationToken.None));
Task.WaitAll(
TEST2websocket.CloseAsync(
WebSocketCloseStatus.NormalClosure,
"",
CancellationToken.None));
Assert.AreEqual(WebSocketState.Closed, TEST2websocket.State);
Assert.AreEqual(WebSocketState.Closed, TEST1websocket.State);
}
You're doing a couple things wrong:
1) you're trying to define route behavior with if/else logic. don't do that.
2) you're not actually declaring what you're trying to hit as part of your pipeline. consider the following:
// https://stackoverflow.com/questions/48216929/how-to-configure-asp-net-core-server-routing-for-multiple-spas-hosted-with-spase
app.Map("/rx", rx => {
rx.UseSpa(rxApp => {
rxApp.Options.SourcePath = "../RX";
if (envIsDevelopment) rxApp.UseProxyToSpaDevelopmentServer("http://localhost:3000");
});
});
app.Map("/V2", ng => {
// https://learn.microsoft.com/en-us/aspnet/core/client-side/spa/angular?view=aspnetcore-2.2
app.UseSpa(angularApp =>
{
angularApp.Options.SourcePath = "../UI";
if (envIsDevelopment) angularApp.UseProxyToSpaDevelopmentServer("http://localhost:4200");
});
});
source
Note that link there: Filip W.'s blog
This is a different use case but it's an example of how you can map two different routes to different destinations. You're trying to switch on the URL and that's not how the pipeline works. It's a declarative pipeline; you have to define the routes according to .NET Core's built-in plugins (or add dependencies that contain other middleware plugins).
Take a look here:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.mapextensions.map?view=aspnetcore-3.1
...and don't reinvent the wheel.
I had looked at the solution you got but it didn't work for me. So, we created a solution for that it does exactly the job that you wanted and works seamlessly for a long time.
https://github.com/damianh/lab/tree/master/dotnet/AspNetCoreNestedApps/AspNetCoreNestedApps
If I summarize with code;
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.IsolatedMap<NestedStartup>("/nested");
app.IsolatedMap<XApp>("/xroute");
app.Run(async context => await context.Response.WriteAsync("Hello World!"));
}
You can separate your applications based on Startup and routing easily. But, keep that in mind somethings might not work for pipeline since you're branching after the main container built. We covered hosted services for branches.
Sorry, this is likely a very amateur question, but I am struggling to understand how to use Moq properly. I am quite new to unit testing as a whole, but I think I'm starting to get the hang of it.
So here's my question... I have this snippet of code below which is using a TestServer in Visual Studio that I using for am Unit Testing... I'm trying to mock IGamesByPublisher so that my test is not reliant on data in the repository (or would it be better to mock GamesByPublisher?... Or do I need to do both?)
public static TestServerWithRepositoryService => new TestServer(services =>
{
services.AddScoped<IGamesByPublisher, GamesByPublisher();
}).AddAuthorization("fake.account", null);
[Fact] // 200 - Response, Happy Path
public async Task GamesByPublisher_GamesByPublisherLookup_ValidRequestData_Produces200()
{
// Arrange
var server = ServerWithRepositoryService;
// Act
var response = await server.GetAsync(Uri);
// Assert
Assert.NotNull(response);
Assert.Equal(HttpStatusCode.OK, response.StatusCode);
}
Here is the IGamesByPublisher
public interface IGamesByPublisher interface.
{
Task<IEnumerable<Publisher>> Execute(GamesByPublisherQueryOptions options);
}
}
I tried
public static TestServerWithRepositoryService => new TestServer(services =>
{
services.AddScoped<Mock<IGamesByPublisher>, Mock<GamesByPublisher>>();
}).AddAuthorization("fake.account", null);
And then I tried
// Not exactly what I attempted, but that code is long gone...
var mock = new Mock<IGamesByPublisher >();
var foo = new GamesByPublisherQueryOptions();
mock.Setup(x => x.Execute(foo)).Returns(true);
I didn't really find great documentation on using Moq, just the quick start guide on GitHub, which I wasn't sure how to apply (probably my own level of experience at fault there...).
I am obviously missing some fundamentals on using Moq...
You were close.
public static TestServerWithRepositoryService => new TestServer(services => {
var mock = new Mock<IGamesByPublisher>();
var publishers = new List<Publisher>() {
//...populate as needed
};
mock
.Setup(_ => _.Execute(It.IsAny<GamesByPublisherQueryOptions>()))
.ReturnsAsync(() => publishers);
services.RemoveAll<IGamesByPublisher>();
services.AddScoped<IGamesByPublisher>(sp => mock.Object);
}).AddAuthorization("fake.account", null);
The above creates the mock, sets up its expected behavior to return a list of publishers any time Execute is invoked with a GamesByPublisherQueryOptions.
It then removes any registrations of the desired interface to avoid conflicts and then registers the service to return the mock any time the interface is requested to be resolved.
There seems to be little information about how to write good unit tests for actual ASP.NET Core controller actions. Any guidance about how to make this work for real?
I've got a system that seems to be working pretty well right now, so I thought I'd share it and see if it doesn't help someone else out. There's a really useful article in the Entity Framework documentation that points the way. But here's how I incorporated it into an actual working application.
1. Create an ASP.NET Core Web App in your solution
There are tons of great articles out there to help you get started. The documentation for basic setup and scaffolding is very helpful. For this purpose, you'll want to create a web app with Individual User Accounts so that your ApplicationDbContext is setup to work with EntityFramework automatically.
1a. Scaffold a controller
Use the information included in the documentation to create a simple controller with basic CRUD actions.
2. Create a separate class library for your unit tests
In your solution, create a new .NET Core Library and reference your newly created web app. In my example, the model I'm using is called Company, and it uses the CompaniesController.
2a. Add the necessary packages to your test library
For this project, I use xUnit as my test runner, Moq for mocking objects, and FluentAssertions to make more meaningful assertions. Add those three libraries to your project using NuGet Package Manager and/or Console. You may need to search for them with the Show Prerelease checkbox selected.
You will also need a couple of packages to use EntityFramework's new Sqlite-InMemory database option. This is the secret sauce. Below are a list of the package names on NuGet:
Microsoft.Data.Sqlite
Microsoft.EntityFrameworkCore.InMemory [emphasis added]
Microsoft.EntityFrameworkCore.Sqlite [emphasis added]
3. Setup Your Test Fixture
Per the article I mentioned earlier, there is a simple, beautiful way to set up Sqlite to work as an in-memory, relational database which you can run your tests against.
You'll want to write your unit test methods so that each method has a new, clean copy of the database. The article above shows you how to do that on a one-off basis. Here's how I set up my fixture to be as DRY as possible.
3a. Synchronous Controller Actions
I've written the following method that allows me to write tests using the Arrange/Act/Assert model, with each stage acting as a parameter in my test. Below is the code for the method and the relevant class properties in the TestFixture that it references, and finally an example of what it looks like to call the code.
public class TestFixture {
public SqliteConnection ConnectionFactory() => new SqliteConnection("DataSource=:memory:");
public DbContextOptions<ApplicationDbContext> DbOptionsFactory(SqliteConnection connection) =>
new DbContextOptionsBuilder<ApplicationDbContext>()
.UseSqlite(connection)
.Options;
public Company CompanyFactory() => new Company {Name = Guid.NewGuid().ToString()};
public void RunWithDatabase(
Action<ApplicationDbContext> arrange,
Func<ApplicationDbContext, IActionResult> act,
Action<IActionResult> assert)
{
var connection = ConnectionFactory();
connection.Open();
try
{
var options = DbOptionsFactory(connection);
using (var context = new ApplicationDbContext(options))
{
context.Database.EnsureCreated();
// Arrange
arrange?.Invoke(context);
}
using (var context = new ApplicationDbContext(options))
{
// Act (and pass result into assert)
var result = act.Invoke(context);
// Assert
assert.Invoke(result);
}
}
finally
{
connection.Close();
}
}
...
}
Here's what it looks like to call the code to test the Create method on the CompaniesController (I use parameter names to help me keep my expressions straight, but you don't strictly need them):
[Fact]
public void Get_ReturnsAViewResult()
{
_fixture.RunWithDatabase(
arrange: null,
act: context => new CompaniesController(context, _logger).Create(),
assert: result => result.Should().BeOfType<ViewResult>()
);
}
My CompaniesController class requires a logger, that I mock up with Moq and store as a variable in my TestFixture.
3b. Asynchronous Controller Actions
Of course, many of the built-in ASP.NET Core actions are asynchronous. To use this structure with those, I've written the method below:
public class TestFixture {
...
public async Task RunWithDatabaseAsync(
Func<ApplicationDbContext, Task> arrange,
Func<ApplicationDbContext, Task<IActionResult>> act,
Action<IActionResult> assert)
{
var connection = ConnectionFactory();
await connection.OpenAsync();
try
{
var options = DbOptionsFactory(connection);
using (var context = new ApplicationDbContext(options))
{
await context.Database.EnsureCreatedAsync();
if (arrange != null) await arrange.Invoke(context);
}
using (var context = new ApplicationDbContext(options))
{
var result = await act.Invoke(context);
assert.Invoke(result);
}
}
finally
{
connection.Close();
}
}
}
It's almost exactly the same, just setup with async methods and awaiters. Below, an example of calling these methods:
[Fact]
public async Task Post_WhenViewModelDoesNotMatchId_ReturnsNotFound()
{
await _fixture.RunWithDatabaseAsync(
arrange: async context =>
{
context.Company.Add(CompanyFactory());
await context.SaveChangesAsync();
},
act: async context => await new CompaniesController(context, _logger).Edit(1, CompanyFactory()),
assert: result => result.Should().BeOfType<NotFoundResult>()
);
}
3c. Async Actions with Data
Of course, sometimes you'll have to pass data back-and-forth between the stages of testing. Here's a method I wrote that allows you to do that:
public class TestFixture {
...
public async Task RunWithDatabaseAsync(
Func<ApplicationDbContext, Task<dynamic>> arrange,
Func<ApplicationDbContext, dynamic, Task<IActionResult>> act,
Action<IActionResult, dynamic> assert)
{
var connection = ConnectionFactory();
await connection.OpenAsync();
try
{
object data;
var options = DbOptionsFactory(connection);
using (var context = new ApplicationDbContext(options))
{
await context.Database.EnsureCreatedAsync();
data = arrange != null
? await arrange?.Invoke(context)
: null;
}
using (var context = new ApplicationDbContext(options))
{
var result = await act.Invoke(context, data);
assert.Invoke(result, data);
}
}
finally
{
connection.Close();
}
}
}
And, of course, an example of how I use this code:
[Fact]
public async Task Post_WithInvalidModel_ReturnsModelErrors()
{
await _fixture.RunWithDatabaseAsync(
arrange: async context =>
{
var data = new
{
Key = "Name",
Message = "Name cannot be null",
Company = CompanyFactory()
};
context.Company.Add(data.Company);
await context.SaveChangesAsync();
return data;
},
act: async (context, data) =>
{
var ctrl = new CompaniesController(context, _logger);
ctrl.ModelState.AddModelError(data.Key, data.Message);
return await ctrl.Edit(1, data.Company);
},
assert: (result, data) => result.As<ViewResult>()
.ViewData.ModelState.Keys.Should().Contain((string) data.Key)
);
}
Conclusion
I really hope this helps somebody getting on their feet with C# and the awesome new stuff in ASP.NET Core. If you have any questions, criticisms, or suggestions, please let me know! I'm still new at this, too, so any constructive feedback is invaluable to me!
In attempts to do some test-driven-development, I've created the most basic, buildable method:
public class NoteService : INoteService
{
public IEnumerable<Annotation> GetNotes(ODataQueryOptions oDataQueryOptions)
{
return new List<Annotation>();
}
}
When trying to unit test it, it seems impossible to create an instance of ODataQueryOptions:
[TestFixture]
public class NoteServiceTests
{
[Test]
public void GetNotes_Returns_IEnumerable_Of_Notes()
{
var sut = new NoteService();
var queryOptions = new ODataQueryOptions(new ODataQueryContext(new EdmCoreModel(), new EdmCollectionType())// new new new etc??
Assert.That(() => sut.GetNotes(options), Is.InstanceOf<IEnumerable<Annotation>>());
}
}
How do you create a simple instance of the object ODataQueryOptions in order to inject it for unit tests?
Will this work?
var request = new HttpRequestMessage(HttpMethod.Get, "");
var context = new ODataQueryContext(EdmCoreModel.Instance, typeof(int));
var options = new ODataQueryOptions(context, request);
I wanted to do something similar and found a workable solution:
My use case
I have a web service that passes OData query parameters down to our CosmosDB document client which translates them into a CosmosDB SQL query.
I wanted a way to write integration tests directly on the CosmosDB client without having to make outgoing calls to other downstream services.
Approaches
Tried mocking ODataQueryParameters using Moq but because it's a class and not an interface, Moq can't properly instantiate all of the properties that I need
Tried instantiating one directly, but outside of an MVC application this is extremely difficult to build the required EdmModel.
Wondered if there is a way to do it without constructing an EdmModel?
I finally figured out a way to do it with the following:
This may not solve every use case, but here's the solution that I landed on for my needs:
public static class ODataQueryOptionsBuilder
{
private static WebApplicationFactory<TEntryPoint> _app =
new WebApplicationFactory<TEntryPoint>();
public static ODataQueryOptions<T> Build<T>(
string queryString)
where T : class
{
var httpContext = new DefaultHttpContext();
httpContext.Request.QueryString = new QueryString(queryString);
httpContext.RequestServices = _app.Services;
var modelBuilder = new ODataConventionModelBuilder();
modelBuilder.EntityType<T>();
var model = modelBuilder.GetEdmModel();
var context = new ODataQueryContext(
model,
typeof(T),
new Microsoft.AspNet.OData.Routing.ODataPath());
return new ODataQueryOptions<T>(context, httpContext.Request);
}
}
Conclusion
I realized that all I needed to get the ODataQueryOptions was a test server that was set up exactly like my web service. Once I realized that, the solution was simple. Use WebApplicationFactory to create the test server, and then allow OData to use the IServiceProvider from that application to build the ODataQueryOptions that I needed.
Drawbacks
Realize that this solution is as performant as your TEntryPoint, so if your application takes a long time to start up, this will cause unit/integration tests to take a long time to run.