J'ai un projet d'API Web ASP.NET Core ciblant .NET Framework 4.7 pour lequel j'essaie d'écrire des tests d'intégration. J'ai créé un projet de test unitaire à l'aide de Visual Studio Ajouter un nouveau projet, puis du modèle de projet de test unitaire (.NET Framework). J'ai ajouté le package NuGet Microsoft.AspNetCore.Mvc.Testing au projet de test, et j'ai le test suivant:
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc.Testing;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace TestRepro.Tests
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public async Task TestMethod1()
{
var factory = new WebApplicationFactory<Startup>();
var client = factory.CreateClient();
var response = await client.GetAsync("/api/values");
}
}
}
Mais cela lève l'exception suivante:
La méthode de test TestRepro.Tests.UnitTest1.TestMethod1 a généré une exception: System.InvalidOperationException: Impossible de trouver «[chemin supprimé] \ TestRepro.Tests \ bin \ Debug \ TestRepro.deps.json». Ce fichier est requis pour que les tests fonctionnels s'exécutent correctement. Il devrait y avoir une copie du fichier dans le dossier bin de votre projet source. Si ce n'est pas le cas, assurez-vous que la propriété PreserveCompilationContext est définie sur true sur votre fichier projet. Par exemple, «vrai». Pour que les tests fonctionnels fonctionnent, ils doivent être exécutés à partir du dossier de sortie de la construction ou le fichier TestRepro.deps.json du répertoire de sortie de votre application doit être copié dans le dossier sur lequel les tests sont exécutés. Une cause courante de cette erreur est l'activation du cliché instantané lors de l'exécution des tests.
J'ai vérifié que TestRepro.deps.json existe dans le dossier de sortie de l'application Web (TestRepro \ bin \ Debug \ net47), mais il n'est pas copié dans le dossier de sortie du projet de test (TestRepro.Tests \ bin \ Debug). Et je n'ai pas été en mesure de savoir comment désactiver la copie d'ombre.
Edit: La documentation dit:
Le package Microsoft.AspNetCore.Mvc.Testing gère les tâches suivantes: Copie le fichier de dépendances (* .deps) du SUT dans le dossier bin du projet de test.
Mais cela ne semble pas fonctionner. Je peux copier le fichier manuellement, mais cela ne fonctionne pas dans un scénario de construction automatisé. Une solution serait d'avoir une étape de construction dans TeamCity, mais cela semble grossier. Des idées?
J'ai un repro sur GitHub si cela aide.
3 Réponses :
Suivez les étapes ci-dessous pour créer un test d'intégration pour Asp.Net Core avec un ciblage net 47.
New Project-> xUnit Test Project(.Net Core)TargetFramework en net47TestReproMicrosoft.AspNetCore.Mvc.TestingAjouter un fichier de test comme ci-dessous
public class BasicTests
: IClassFixture<WebApplicationFactory<Startup>>
{
private readonly WebApplicationFactory<Startup> _factory;
public BasicTests(WebApplicationFactory<Startup> factory)
{
_factory = factory;
}
[Fact]
public async Task TestMethod1()
{
var client = _factory.CreateClient();
var response = await client.GetAsync("/api/values");
}
}
Exécuter le projet de test
Oui, cela fonctionne réellement! Mais je ne comprends pas pourquoi. Est-ce parce qu'il a commencé comme un projet .NET Core, puis a été reciblé? Ou est-ce parce qu'il utilise xUnit plutôt que le framework MSTest?
@HenrikOlsson Je suppose que c'est lié à MSTest . Pour la doc, il est utilisé avec xunit test.
Non, ce n'est pas le cas - j'ai juste essayé de créer un projet MSTest de la même manière, comme dans votre réponse, et cela a également fonctionné. Donc ma conclusion est que vous devez commencer par target .Net Core, puis changer de cible.
Cela n'a pas résolu mon problème lorsque je veux cibler .net core. Que devrais-je faire?
@SamuelJ ma réponse résout-elle votre problème?
Oui, il en a l'air. Merci @TylerOhlsen et Henrik Olsson pour votre soutien inlassable.
Veuillez noter que cela ne fonctionne que si vous choisissez Microsoft.AspNetCore.Mvc.Testing version 2.xy Les versions 3.0.0 et supérieures ne fonctionnent que sur dotnet core.
Je viens de rencontrer ce même problème et j'ai trouvé que la cause profonde était assez obscure. À partir de la documentation , les fichiers .deps doivent être copiés dans le répertoire bin du projet de test d'intégration. Cela ne se produisait pas pour moi car je ne faisais pas explicitement référence au package Microsoft.AspNetCore.Mvc.Testing de mon projet de test d'intégration. J'avais créé une bibliothèque partagée avec certaines fonctions utilitaires qui référencaient ce package nuget, donc mon projet de test d'intégration l'a référencé indirectement.
Il existe des tâches de génération personnalisées dans le package Microsoft.AspNetCore.Mvc.Testing qui copient les fichiers deps.json service référencé pour vous, vous devez donc le référencer directement à partir du projet de test d'intégration afin d'exécuter ces tâches de génération.
Si vous rencontrez le même problème que celui indiqué ci-dessus et que vous utilisez .net core, la solution décrite dans cette réponse est exactement ce dont vous avez besoin. J'avais oublié cela aussi dans mon projet de test d'intégration. Merci beaucoup pour votre réponse @TylerOhlsen.
C'était aussi la solution pour moi. Les tests fonctionnaient jusqu'à ce que j'aie créé une bibliothèque partagée et refactorisé les dépendances en double. Le projet de tests unitaires doit faire référence à Microsoft.AspNetCore.Mvc.Test pour que le vaudou avec deps.json ait lieu.
Pour moi, j'avais déjà une référence à Microsoft.AspNetCore.Mvc.Test dans mon projet de test, mais la suppression de ce qui suit a résolu le problème:
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
Cela a essentiellement résolu le problème pour moi lors de la mise à niveau vers .NET 5.0, ce qui est étrange. Mais j'ai une information d'assemblage partagée, alors j'ai supprimé cette ligne et l'ai remplacée par: <GenerateAssemblyProductAttribute> false </ GenerateAssemblyPro ductAttribute> <GenerateAssemblyCompanyAttribute> false </ GenerateAssemblyCom panyAttribute> <GenerateAssemblyFileVersionAttribute> <GenerateAssemblyFileVersionAttribute> GenerateAssemblyInformationalVersionAttribute> false </ Genera teAssemblyInformatio nalVersionAttribute> <GenerateAssemblyVersionAttribute> false </ GenerateAssemblyVer sionAttribute>