web-dev-qa-db-fra.com

Aucun assemblage de test trouvé correspondant au modèle: ** \ * Test * .dll,! ** \ * TestAdapter.dll,! ** \ obj \ **

J'essaie d'implémenter un processus d'enregistrement sécurisé dans Azure DevOps (VSTS) basé sur le succès des tests unitaires. Cependant, je reçois constamment cet avertissement/erreur que les assemblys ne sont pas trouvés.

##[warning]No test assemblies found matching the pattern: **\*Test*.dll,!**\*TestAdapter.dll,!**\obj\**.
##[debug]Processed: ##vso[task.issue type=warning;]No test assemblies found matching the pattern: **\*Test*.dll,!**\*TestAdapter.dll,!**\obj\**.
======================================================

Tous mes tests unitaires s'exécutent avec succès dans Visual Studio 2017 dans Test Explorer localement.

Le documentation Azure DevOps semble simple mais cela ne fonctionne pas quand je le suis.

J'utilise un agent VS2017 hébergé. Le CI Build lui-même réussit lors de l'archivage du contrôle de source TFS.

Journal

écran 1
écran 2écranécran 4écran 5 [écran 6]

azure-pipelines
12
Andy Miller

Le "vieux" .NET avait les fichiers situés dans le dossier Release (qui est décrit par la variable BuildConfiguration).

Les versions de .NET Core contiennent un dossier supplémentaire:

Folder structure

YourNamespaceHere.UnitTests > bin > Release > netcoreapp2.1 > dll's

Lorsque vous ajoutez un caractère générique supplémentaire, la génération trouvera les DLL les plus unittests.

**\$(BuildConfiguration)\*\*unittests.dll

J'ai renommé la partie *Tests* En *unittests.dll Car mon projet contient également des tests d'intégration.

enter image description here

4
JeroenW

J'ai eu ce même problème dans un projet .Net Core 2.1. Dans les "autres options de la console", vous souhaitez ajouter:

/Framework:.NETCoreApp,Version=v2.1 /logger:console;verbosity="normal"

Veuillez noter que j'ai eu un autre problème non lié à cela, mais sur la même tâche. J'obtenais une erreur de ne pas trouver une sortie de résultat de fichier de test pour les DLL TestPlatform. J'ai donc ajouté ce filtre aux fichiers de test existants:

!**\*Microsoft.VisualStudio.TestPlatform*

Mon dernier yaml ressemble à ceci:

- task: VSTest@2
  displayName: 'Run Unit Tests'
  inputs:
    testAssemblyVer2: |
     **\$(BuildConfiguration)\*test*.dll
     **\$(BuildConfiguration)\**\*test*.dll
     !**\*Microsoft.VisualStudio.TestPlatform*
     !**\obj\**
    vstestLocationMethod: 'location'
    vstestLocation: 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\TestPlatform\'
    codeCoverageEnabled: True
    otherConsoleOptions: '/platform:x64 /Framework:.NETCoreApp,Version=v2.1 /logger:console;verbosity="normal" '
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'
1
Antebios

J'ai eu le même problème lorsque ma tâche de test unitaire a voulu s'exécuter (j'utilise .Net Core). Cela semble être un problème de dénomination de chemin. Mon projet de test unitaire s'appelle

SimpleExample.UnitTests

mais le chemin d'accès de la tâche "DotNetCoreCLI @ 2" dans le fichier YAML a été défini sur

"**/* Tests/*. Csproj"

Je modifie donc simplement le chemin du projet de la tâche de test unitaire pour qu'il ressemble à la deuxième partie (après le point) de mon projet de tests unitaires dans Visual Studio.

Le chemin de mon projet de test unitaire dans Visual Studio 2017:Desktop\Azure-DevOps-Test\SimpleExample.UnitTests

La tâche YAML qui exécute les tests unitaires [Pour les projets .Net]:

- task: DotNetCoreCLI@2
    displayName: 'Runing Unit Tests'
    inputs:
      command: test
      projects: '**/*UnitTests/*.csproj'
      arguments: '--configuration $(buildConfiguration)'
1
Alireza Sattari

J'ai eu le même problème et j'ai passé des siècles à essayer différents modèles de correspondance de fichiers, versions .NET Core, etc.

Mon pipeline de génération publiait les tests dans le répertoire des artefacts, ce que vous pouvez facilement faire avec une commande de publication. Mais mon agent de test ne téléchargeait pas les artefacts et c'était le problème. J'utilisais différents agents pour le déploiement et pour les tests, donc je n'ai pas remarqué que quelque chose n'allait pas parce que l'agent de déploiement avait accès aux ressources, mais pas l'agent de test.

Assurez-vous que vous avez choisi de télécharger les artefacts dans la section Téléchargement d'artefacts de l'onglet de configuration de l'agent. C'est tout en bas et je pense que par défaut, il a montré mon package de construction, ce qui me fait penser qu'il est en cours de téléchargement. Mais je devais encore l'étendre et cocher l'option "sélectionner tous les artefacts". S'il est correctement configuré, vous devriez avoir une tâche de téléchargement d'artefact dans vos journaux de déploiement.

Tâche de publication de mon pipeline de génération:

- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '**/*ServiceTests.csproj'
    arguments: '-c $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)/servicetests'
    modifyOutputPath: false
    zipAfterPublish: false

Mon agent de test Section Téléchargement d'artefacts: enter image description here

Configuration de sélection de ma tâche de test: enter image description here

0
Michal Ciesielski