WebApplicationFactory and release pipeline - integration-testing

I am new to WebApplicationFactory use and want to know
what is the use of this WebApplicationFactory class for integration tests. as my understanding, it is useful only for mocking external services (this is what we do in unit tests).
Should we use WebApplicationFactory for simple web api integration testing?
what happens in release pipelines?
when i run integration tests (written using WebApplicationFactory) open the web api automatically and uses overrided appsettings set in a custom WebApplicationFactory class.
so when i publish the tests code on azure and creates release pipeline stage for integration tests. does the above test code (custom WebApplicationFactory ) override the actual app dll's appsetting. ( i mean does it start the app and use test appsetting logic)

MSFT has pretty good documentation about integration testing and the usage of WebApplicationFactory to help facilitate this type of testing for Web Applications. This is a good place to learn why integration testing is done and how to do it with WebApplicationFactory.
What is the use of this WebApplicationFactory class for integration tests?
The WebApplicationFactory helps you build an in-memory Http Server and an HttpClient capable of making requests on that server.
By default, WebApplicationFactory will build this server using all the same services and dependencies that are registered in the application you are testing. You can, if desired, modify the services that are registered to the IServiceCollection so that Fakes or Mocks can be used instead of concrete implementations, but this is more of a feature of WebApplicationFactory and not its purpose. Whether you use Mocks or not should depend on what you're trying to test, and whether it's OK to use the application's services for testing purposes.
WebApplicationFactory helps test the configuration and middleware pipeline of your web application in a way that unit tests can't. By making HTTP requests into your in-memory server, you're able to ensure your application and its endpoints are working properly.
What happens in release pipelines?
Your integration tests should be in a separate project from your main application. You don't want the integration test project to be in your release pipeline and, unless you have a good reason to, it shouldn't be published to Azure.

Related

Stand up a ASP.Net Core Web API service in an NUnit Test

I have a NuGet package that I am trying to write some integration tests around. I am using NUnit to run these tests.
I would like to stand up a basic Web API service using .Net 6.0. Most of the examples I see require a full project dedicated to running the service.
Is there a way I can standup a simple Web API service in the [setup] of my test?
It can just run on localhost and only need a single GET operation.

Automated Unit test using Xunit for .net core 2.2 web API

I have an Web API application build in .net core 2.2, I have to write automated test for this application using Xunit. Application involves dependency injection at two level Wep API => Service layer => Repository layer.
Can you suggest ideal approach to write these tests that involves mocking database context?
A unit test should only ever mock the immediate level of dependencies. For example, if you were testing a controller, you'd mock the service. If you were testing the service, you'd mock the repository, and if you were testing the repository, you'd mock the context (or rather just use the in-memory database if using EF Core).
In other words, you don't build up layers of mocks. The mock should completely abstract the functionality. For the controller example, you'd mock the service to just return some canned value. The service mock would not actually utilize any repository.

Owin.Testing TestServer with Windsor container and Moq

I have a WebApi where I am using Windsor Castle as a IoC framework. I am using Owin library and a startup file was created to centralized the configuration of the API. Everything works as expected.
I have integration tests where I am using Owin.Testing library and the server is started using a test startup class which is inheriting the real one. The Windsor container was successfully configured for the TestServer. The integration tests are executing web requests against the running self hosted server. Everything works fine.
There are two things which are not working when using the test server:
the ModelState of the controller is all the time valid even when I am passing an invalid json body for the POST request. When hosted with IIS it works as expected. Any idea what can be wrong with the test server?
I am using VS test runner and the Owin TestServer is initialized in a [ClassInitialize] method. I do not want to create a new test server after each test as Windsor container initialization is quite expensive. There are tests where I need to mock some 3rd party services (by using Register method of the container and Moq). At the end of each test I want to rollback all the mocks from the container which were done in the scope of executed test. Is it possible somehow to do it? I have tried to register within a scope but does not work.
Thanks

Wsdl, test web service, newbie

I have a few wsdl URLs (e.g. https://location?wsdl). And I need to automate the testing of these web services with asp.net. How can I do that ? I was told that http website request could do this (HttpRequest Class). I don't know much about web services except the basics.
Create a unit test project. Use "Add Service Reference" to reference the WSDLs within this project. Then, just create unit tests to call the service and confirm that the results are as expected.
Note that purists will say these are integration tests, not unit tests, but that's ok. They'll be automated, which is what you were looking for.
Soap UI works great if you can get around the requirement of having to using ASP.NET.
See the tutorial here...
http://www.soapui.org/Getting-Started/your-first-soapui-project.html
If you have to use .NET why can't you just make a proxy class of the webservice using wsdl.exe and then test it with the web service client that's generated from that?

Automating WSDL.exe in a Custom Build

I have a web application written in C# that consumes several internal web services. We have a development tier, a testing tier, and a production tier. Also, we use the WSDL.exe command to generate a Proxies.cs file for a given tier's web services.
When we are ready to deploy our code up the stack from development to test or test to production, we need to run the WSDL.exe command to point to the appropriate version of the web services.
Is there a generally accepted way to automate this?
There are a number of way to do it. A NAnt build script will do it, but I think the most commonly accepted method now is to use MSBuild. See MSDN for details.
Our company uses a combination of NANT + Cruise Control + Custom Utility apps to build our products. More specifically, the task in NANT will allow you to fire off those command-line applications such as WSDL.exe

Resources