Un aspetto storicamente spesso problematico, è sempre stato quello di eseguire integration test su un'applicazione in maniera affidabile. Ci sono molteplici scogli da superare, per esempio avere un server attivo su cui effettuare le chiamate, o integrarsi con un database, ma spesso questi strumenti sono l'unico modo per verificare il corretto comportamento di componenti quali filtri, controller, middleware, ecc.
Come sappiamo, ASP.NET Core contiene al suo interno il web server Kestrel, cosa che semplifica di molto il nostro compito, visto che
- non dobbiamo integrarci con un server esterno e
- possiamo controllarne la configurazione e lo startup da C#.
Immaginiamo di aver creato un progetto Web API - per esempio il template di default - e di voler invocare WeatherForecastController per verificarne la risposta. Per prima cosa abbiamo bisogno di avviare il Kestrel. Allo scopo, è sufficiente che il nostro progetto di test referenzi la web application e, se stiamo usando XUnit, possiamo semplicemente invocare il metodo Program.Main nel costruttore della nostra classe di test:
public class WeatherControllerTests
{
public WeatherControllerTests()
{
Task.Run(() => WebApplication1.Program.Main(new string[0]));
}
// .. qui test code ..
}Il codice è piuttosto elementare, l'unica nota riguarda il fatto che la chiamata a Program.Main per avviare Kestrel è bloccante, e pertanto dobbiamo eseguirla all'interno di un Task in background.
A questo punto, il nostro server è effettivamente raggiungibile e possiamo finalmente scrivere il nostro test:
[Fact]
public async Task WeatherController_ReturnsWeatherData()
{
var client = new HttpClient();
var response = await client.GetAsync("https://localhost:5001/WeatherForecast");
response.EnsureSuccessStatusCode();
var result = JsonConvert.DeserializeObject<IEnumerable<WeatherForecast>>(
await response.Content.ReadAsStringAsync());
Assert.NotEmpty(result);
}Come possiamo notare, si tratta di un vero e proprio integration test, visto che non stiamo invocando il controller come oggetto .NET, ma stiamo effettuando una chiamata HTTP verso un endpoint.
L'esempio è volutamente banale, dato che WeatherController non ha alcuna dipendenza verso oggetti esterni (database, servizi, ecc.). In un prossimo script vedremo come effettuare il mocking di eventuali dipendenze così da rendere i nostri test più controllabili e veloci da eseguire.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Semplificare i deployment con le label in Azure Container App
Blue/Green Release in locale con .NET Aspire
Ricerca delle GitHub issue tramite operatori logici
Integrare un LLM in ASP.NET Core con Microsoft.Extensions.AI
Utilizzare il Null conditional assignment di C# 14
Creare un extension method per applicare condizionalmente una Where in una query LINQ per Entity Framework
Gestione dei prompt file a livello di organizzazione aziendale in GitHub
Integrare OpenTelemetry direttamente in Azure Monitor
Gestione opzioni colonna nella Blazor QuickGrid
Costruire endpoint SSE in ASP.NET Core
Middleware e telemetria alle chiamate AI con Microsoft.Extensions.AI
Ottimizzare gli indici con Automatic Index Compaction in Azure SQL Database
I più letti di oggi
- Effettuare il multi-checkout in linea nelle pipeline di Azure DevOps
- Accedere a risorse e immagini in Windows Store app di Windows 8
- Alleggerire le applicazioni WPF sfruttando gli oggetti Freezable
- Permettere il Drag-and-drop solo su zone predefinite con Silverlight 2.0
- Consumare dati binari in realtime lato client con ASP.NET Core SignalR
- Effetto turnstile su tutte le pagine con il Windows Phone Toolkit
- Personalizare l'icona e le funzionalità di un sito web per iOS e IE
- Caricamenti veloci da CDN e fallback locale con ASP.NET Core
- Utilizzare dati in formato XML in XAML
- Accedere a dati esposti con WebService con Silverlight 1.0


