dotnet-test met VSTest

Dit artikel is van toepassing op: ✔️ .NET 6 SDK en latere versies

Naam

dotnet test - .NET-teststuurprogramma dat wordt gebruikt voor het uitvoeren van eenheidstests met VSTest.

Samenvatting

dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL> | <EXE>]
    [--test-adapter-path <ADAPTER_PATH>]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [--blame]
    [--blame-crash]
    [--blame-crash-dump-type <DUMP_TYPE>]
    [--blame-crash-collect-always]
    [--blame-hang]
    [--blame-hang-dump-type <DUMP_TYPE>]
    [--blame-hang-timeout <TIMESPAN>]
    [-c|--configuration <CONFIGURATION>]
    [--collect <DATA_COLLECTOR_NAME>]
    [-d|--diag <LOG_FILE>]
    [--disable-build-servers]
    [-f|--framework <FRAMEWORK>]
    [-e|--environment <NAME="VALUE">]
    [--filter <EXPRESSION>]
    [--interactive]
    [-l|--logger <LOGGER>]
    [--no-build]
    [--nologo]
    [--no-restore]
    [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>]
    [--results-directory <RESULTS_DIR>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-s|--settings <SETTINGS_FILE>]
    [-t|--list-tests]
    [--tl:[auto|on|off]]
    [-v|--verbosity <LEVEL>]
    [<args>...]
    [[--] <RunSettings arguments>]

dotnet test -h|--help

Description

De dotnet test opdracht wordt gebruikt om eenheidstests uit te voeren in een bepaalde oplossing. De dotnet test opdracht bouwt de oplossing en voert een testhosttoepassing uit voor elk testproject in de oplossing met behulp van VSTest. De testhost voert tests uit in het opgegeven project met behulp van een testframework, bijvoorbeeld: MSTest, NUnit of xUnit, en rapporteert het slagen of mislukken van elke test. Als alle tests zijn geslaagd, retourneert de testloper 0 als afsluitcode; als een test mislukt, wordt 1 geretourneerd.

Opmerking

dotnet test oorspronkelijk ontworpen ter ondersteuning van alleen VSTestop -gebaseerde testprojecten. Recente versies van de testframeworks voegen ondersteuning toe voor Microsoft.Testing.Platform. Dit alternatieve testplatform is lichtgewicht en sneller dan VSTest en ondersteunt dotnet test met verschillende opdrachtregelopties. Zie dotnet-test met MTP voor meer informatie.

Voor projecten met meerdere doelgroepen worden tests uitgevoerd voor elk doelframework. De testhost en het eenheidstestframework zijn verpakt als NuGet-pakketten en worden hersteld als gewone afhankelijkheden voor het project. Vanaf de .NET 9 SDK worden deze tests standaard parallel uitgevoerd. Als u parallelle uitvoering wilt uitschakelen, stelt u de TestTfmsInParallel eigenschap MSBuild in op false. Zie Tests parallel uitvoeren en de voorbeeldopdrachtregel verderop in dit artikel voor meer informatie.

Testprojecten geven de testloper op met behulp van een gewoon <PackageReference> element, zoals te zien is in het volgende voorbeeldprojectbestand:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.10.0" />
    <PackageReference Include="xunit" Version="2.8.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.8.1" />
  </ItemGroup>

</Project>

Waar Microsoft.NET.Test.Sdk is de testhost, xunit is het testframework. En xunit.runner.visualstudio is een testadapter, waarmee het xUnit-framework kan werken met de testhost.

Impliciete herstelbewerking

U hoeft dotnet restore niet uit te voeren omdat deze impliciet wordt uitgevoerd door alle opdrachten waarvoor een herstelbewerking is vereist, zoals dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishen dotnet pack. Als u impliciet herstellen wilt uitschakelen, gebruikt u de optie --no-restore.

De dotnet restore opdracht is nog steeds nuttig in bepaalde scenario's waarin expliciet herstellen zinvol is, zoals builds voor continue integratie in Azure DevOps Services of in buildsystemen die expliciet moeten worden beheerd wanneer het herstellen plaatsvindt.

Zie de dotnet restore documentatievoor meer informatie over het beheren van NuGet-feeds.

Downloads van workloadmanifesten

Wanneer u deze opdracht uitvoert, wordt er een asynchrone achtergronddownload van reclamemanifesten voor workloads gestart. Als het downloaden nog steeds wordt uitgevoerd wanneer deze opdracht is voltooid, wordt het downloaden gestopt. Zie Reclamemanifestenvoor meer informatie.

Arguments

PROJECT | SOLUTION | DIRECTORY | DLL | EXE
- Pad naar het testproject.
- Pad naar de oplossing.
- Pad naar een map die een project of oplossing bevat.
- Pad naar een testproject .dll bestand.
- Pad naar een testproject .exe bestand.
Als dit niet is opgegeven, is het effect hetzelfde als het gebruik van het DIRECTORY argument om de huidige map op te geven.

Options

Waarschuwing

Belangrijke wijzigingen in opties:

Vanaf .NET 7: overschakelen -a naar alias --arch in plaats van --test-adapter-path
Vanaf .NET 7: overschakelen -r naar alias --runtime in plaats van --results-directory

--test-adapter-path <ADAPTER_PATH>

Pad naar een map die moet worden gezocht naar extra testadapters. Alleen .dll bestanden met achtervoegsel .TestAdapter.dll worden gecontroleerd. Als dit niet is opgegeven, wordt de map van de test -.dll doorzocht.

Korte vorm -a beschikbaar in .NET SDK-versies ouder dan 7.
-a|--arch <ARCHITECTURE>

Hiermee geeft u de doelarchitectuur. Dit is een verkorte syntaxis voor het instellen van de Runtime Identifier (RID), waarbij de opgegeven waarde wordt gecombineerd met de standaard-RID. Als u bijvoorbeeld op een win-x64 computer opgeeft --arch x86 de RID instelt op win-x86. Als u deze optie gebruikt, gebruikt u de optie -r|--runtime niet. Beschikbaar sinds .NET 6 Preview 7.
--artifacts-path <ARTIFACTS_DIR>

Alle builduitvoerbestanden van de uitgevoerde opdracht worden weergegeven in submappen onder het opgegeven pad, gescheiden door project. Zie Indeling voor uitvoer van artefactenvoor meer informatie. Beschikbaar sinds .NET 8 SDK.
--blame

Voert de tests uit in de schuldmodus. Deze optie is handig bij het isoleren van problematische tests waardoor de testhost vastloopt. Wanneer er een crash wordt gedetecteerd, wordt er een reeksbestand gemaakt waarin TestResults/<Guid>/<Guid>_Sequence.xml de volgorde wordt vastgelegd van tests die vóór de crash zijn uitgevoerd.

Met deze optie maakt u geen geheugendump en is dit niet handig wanneer de test vasthangt.
--blame-crash (Beschikbaar sinds .NET 5.0 SDK)

Voert de tests uit in de foutmodus en verzamelt een crashdump wanneer de testhost onverwacht wordt afgesloten. Deze optie is afhankelijk van de versie van .NET die wordt gebruikt, het type fout en het besturingssysteem.

Voor uitzonderingen in beheerde code wordt automatisch een dump verzameld op .NET 5.0 en latere versies. Er wordt een dump gegenereerd voor testhost of een onderliggend proces dat ook is uitgevoerd op .NET 5.0 en is vastgelopen. Crashes in systeemeigen code genereren geen dump. Deze optie werkt in Windows, macOS en Linux.

Crashdumps in systeemeigen code of wanneer u .NET Core 3.1 of eerdere versies gebruikt, kunnen alleen worden verzameld in Windows met behulp van Procdump. Een map met procdump.exe en procdump64.exe moet zich in de omgevingsvariabele PATH of PROCDUMP_PATH bevinden. Download de hulpprogramma's. Impliceert --blame.

Als u een crashdump wilt verzamelen van een systeemeigen toepassing die wordt uitgevoerd op .NET 5.0 of hoger, kan het gebruik van Procdump worden geforceerd door de VSTEST_DUMP_FORCEPROCDUMP omgevingsvariabele in te stellen op 1.
--blame-crash-dump-type <DUMP_TYPE> (Beschikbaar sinds .NET 5.0 SDK)

Het type crashdump dat moet worden verzameld. Ondersteunde dumptypen zijn full (standaard) en mini. Impliceert --blame-crash.
--blame-crash-collect-always (Beschikbaar sinds .NET 5.0 SDK)

Hiermee wordt een crashdump verzameld bij de verwachte en onverwachte afsluit van de testhost.
--blame-hang (Beschikbaar sinds .NET 5.0 SDK)

Voer de tests uit in de foutmodus en verzamelt een vastlopend dump wanneer een test de opgegeven time-out overschrijdt.
--blame-hang-dump-type <DUMP_TYPE> (Beschikbaar sinds .NET 5.0 SDK)

Het type crashdump dat moet worden verzameld. Het moet zijn full, miniof none. Wanneer none dit is opgegeven, wordt de testhost beëindigd bij time-out, maar er wordt geen dump verzameld. Impliceert --blame-hang.
--blame-hang-timeout <TIMESPAN> (Beschikbaar sinds .NET 5.0 SDK)

Time-out per test, waarna een hangdump wordt geactiveerd en het testhostproces en alle onderliggende processen worden gedumpt en beëindigd. De time-outwaarde wordt opgegeven in een van de volgende indelingen:
- 1,5 uur, 1,5 uur, 1,5 uur
- 90m, 90min, 90minute, 90minutes
- 5400s, 5400 sec, 5400second, 5400seconds
- 5400000ms, 5400000mil, 5400000milliseconden, 5400000milliseconden
Wanneer er geen eenheid wordt gebruikt (bijvoorbeeld 5400000), wordt uitgegaan van een waarde in milliseconden. Bij gebruik in combinatie met gegevensgestuurde tests is het time-outgedrag afhankelijk van de gebruikte testadapter. Voor xUnit, NUnit en MSTest 2.2.4+ wordt de time-out na elke testcase vernieuwd. Voor MSTest vóór versie 2.2.4 wordt de time-out gebruikt voor alle testcases. Deze optie wordt ondersteund in Windows met netcoreapp2.1 en hoger, in Linux met netcoreapp3.1 en hoger en in macOS met net5.0 of hoger. Impliceert --blame en --blame-hang.
-c|--configuration <CONFIGURATION>

Definieert de buildconfiguratie. De standaardinstelling voor de meeste projecten is Debug, maar u kunt de buildconfiguratie-instellingen in uw project overschrijven.
--collect <DATA_COLLECTOR_NAME>

Hiermee schakelt u gegevensverzamelaar in voor de testuitvoering. Zie Testuitvoering bewaken en analyseren voor meer informatie.

U kunt bijvoorbeeld codedekking verzamelen met behulp van de --collect "Code Coverage" optie. Zie Codedekking gebruiken, Analyse van codedekking aanpassen en Dotnet/docs#34479 van GitHub-probleem gebruiken.

Als u codedekking wilt verzamelen, kunt u Coverlet ook gebruiken met behulp van de --collect "XPlat Code Coverage" optie.
-d|--diag <LOG_FILE>

Hiermee schakelt u de diagnostische modus voor het testplatform in en schrijft u diagnostische berichten naar het opgegeven bestand en naar bestanden ernaast. Het proces waarmee de berichten worden vastgelegd, bepaalt welke bestanden worden gemaakt, zoals *.host_<date>.txt voor het testhostlogboek en *.datacollector_<date>.txt voor het logboek van de gegevensverzamelaar.
--disable-build-servers

Hiermee wordt de opdracht gedwongen om permanente buildservers te negeren. Deze optie biedt een consistente manier om al het gebruik van buildcaching uit te schakelen, waardoor een volledig nieuwe build wordt afgemaakt. Een build die niet afhankelijk is van caches is handig wanneer de caches om een of andere reden beschadigd of onjuist zijn. Beschikbaar sinds .NET 7 SDK.
-e|--environment <NAME="VALUE">

Hiermee stelt u de waarde van een omgevingsvariabele in. Hiermee maakt u de variabele als deze niet bestaat, overschrijft deze als deze wel bestaat. Met deze optie worden de tests geforceerd uitgevoerd in een geïsoleerd proces. De optie kan meerdere keren worden opgegeven om meerdere variabelen op te geven.
-f|--framework <FRAMEWORK>

Het doelframework moniker (TFM) van het doelframework om tests voor uit te voeren. Het doelframework moet ook worden opgegeven in het projectbestand.
--filter <EXPRESSION>

Filtert tests in het huidige project met behulp van de opgegeven expressie. Alleen tests die overeenkomen met de filterexpressie worden uitgevoerd. Zie de sectie Details van filteropties voor meer informatie. Zie Selectief eenheidstests uitvoeren voor meer informatie en voorbeelden over het gebruik van selectief eenheidstests.
-?|-h|--help

Hiermee wordt een beschrijving afgedrukt van hoe de opdracht gebruikt moet worden.
--interactive

Hiermee kan de opdracht stoppen en wachten op invoer of actie van de gebruiker. Bijvoorbeeld om de verificatie te voltooien.
-l|--logger <LOGGER>

Hiermee geeft u een logger voor testresultaten en optioneel schakelopties voor de logger. Geef deze parameter meerdere keren op om meerdere logboekregistraties in te schakelen. Zie Testresultaten rapporteren, Switches voor loggers en de voorbeelden verderop in dit artikel voor meer informatie.

Als u opdrachtregelswitches wilt doorgeven aan de logboekregistratie:
- Gebruik de volledige naam van de schakeloptie, niet het afgekorte formulier (bijvoorbeeld verbosity in plaats van v).
- Laat alle voorloopstreepjes weg.
- Vervang de ruimte die elke schakelaar scheidt door een puntkomma ;.
- Als de schakeloptie een waarde heeft, vervangt u het dubbele puntscheidingsteken tussen die schakeloptie en de bijbehorende waarde door het gelijkteken =.
Zo zou -v:detailed --consoleLoggerParameters:ErrorsOnly bijvoorbeeld verbosity=detailed;consoleLoggerParameters=ErrorsOnly worden.
--no-build

Het testproject wordt niet gebouwd voordat het wordt uitgevoerd. Ook wordt de vlag --no-restore impliciet ingesteld.
--nologo

Voer tests uit zonder de banner microsoft TestPlatform weer te geven. Beschikbaar sinds .NET Core 3.0 SDK.
--no-restore

Voert geen impliciete herstelbewerking uit bij het uitvoeren van de opdracht.
-o|--output <OUTPUT_DIRECTORY>

Map waarin de binaire bestanden moeten worden uitgevoerd. Als dit niet is opgegeven, is ./bin/<configuration>/<framework>/het standaardpad . Voor projecten met meerdere doelframeworks (via de TargetFrameworks eigenschap) moet u ook definiëren --framework wanneer u deze optie opgeeft. dotnet test voert altijd tests uit vanuit de uitvoermap. U kunt testassets gebruiken AppDomain.BaseDirectory in de uitvoermap.
- .NET 7.0.200 SDK en hoger
  
  Als u de --output optie opgeeft bij het uitvoeren van deze opdracht op een oplossing, verzendt de CLI een waarschuwing (een fout in 7.0.200) vanwege de onduidelijke semantiek van het uitvoerpad. De optie --output is niet toegestaan omdat alle uitvoer van alle gebouwde projecten wordt gekopieerd naar de opgegeven map, die niet compatibel is met projecten met meerdere doelgroepen, evenals projecten met verschillende versies van directe en transitieve afhankelijkheden. Zie optie --output op oplossingsniveau niet meer geldig is voor build-gerelateerde opdrachtenvoor meer informatie.
--os <OS>

Hiermee geeft u het doelbesturingssysteem (OS). Dit is een verkorte syntaxis voor het instellen van de Runtime Identifier (RID), waarbij de opgegeven waarde wordt gecombineerd met de standaard-RID. Als u bijvoorbeeld op een win-x64 computer opgeeft --os linux de RID instelt op linux-x64. Als u deze optie gebruikt, gebruikt u de optie -r|--runtime niet. Beschikbaar sinds .NET 6.
--results-directory <RESULTS_DIR>

De map waar de testresultaten worden geplaatst. Als de opgegeven map niet bestaat, wordt deze gemaakt. De standaardwaarde bevindt zich TestResults in de map die het projectbestand bevat.

Korte vorm -r beschikbaar in .NET SDK-versies ouder dan 7.
-r|--runtime <RUNTIME_IDENTIFIER>

De doelruntime om op te testen.

Korte vorm -r beschikbaar vanaf .NET SDK 7.
-s|--settings <SETTINGS_FILE>

Het .runsettings bestand dat moet worden gebruikt voor het uitvoeren van de tests. Het TargetPlatform element (x86|x64) heeft geen effect voor dotnet test. Als u tests wilt uitvoeren die zijn gericht op x86, installeert u de x86-versie van .NET Core. De bitness van de dotnet.exe die zich op het pad bevindt, is wat wordt gebruikt voor het uitvoeren van tests. Zie de volgende bronnen voor meer informatie:
- Eenheidstests configureren met behulp van een .runsettings bestand.
- een testuitvoering configureren
-t|--list-tests

Vermeld de gedetecteerde tests in plaats van de tests uit te voeren.
--tl:[auto|on|off]

Hiermee geeft u op of Terminal Logger moet worden gebruikt voor de build-uitvoer. De standaardwaarde is auto, waarmee eerst de omgeving wordt geverifieerd voordat u terminallogboekregistratie inschakelt. De omgevingscontrole controleert of de terminal in staat is moderne uitvoerfuncties te gebruiken en geen omgeleide standaarduitvoer gebruikt voordat de nieuwe logger wordt ingeschakeld. on de omgevingscontrole overslaat en terminallogboekregistratie inschakelt. off de omgevingscontrole overslaat en de standaardconsolelogger gebruikt.

Terminal Logger toont de herstelfase, gevolgd door de buildfase. Tijdens elke fase worden de huidige bouwprojecten onderaan de terminal weergegeven. Elk project dat wordt gebouwd, levert zowel het MSBuild-doel dat momenteel wordt gebouwd als de hoeveelheid tijd die aan dat doel is besteed. U kunt deze informatie doorzoeken voor meer informatie over de build. Wanneer een project klaar is met bouwen, wordt één sectie 'build completed' geschreven die het volgende vastlegt:
- De naam van het gebouwde project.
- Het doelframework (indien multi-targeted).
- De status van die build.
- De primaire uitvoer van die build (die is hyperlinked).
- Diagnostische gegevens die voor dat project worden gegenereerd.
Deze optie is beschikbaar vanaf .NET 8.
-v|--verbosity <LEVEL>

Hiermee stelt u het uitgebreidheidsniveau van de opdracht in. Toegestane waarden zijnq[uiet], , , m[inimal]en n[ormal]d[etailed]diag[nostic]. De standaardwaarde is minimal. Zie LoggerVerbosity voor meer informatie.
args

Hiermee geeft u extra argumenten op die moeten worden doorgegeven aan de adapter. Gebruik een spatie om meerdere argumenten te scheiden.

De lijst met mogelijke argumenten is afhankelijk van het opgegeven gedrag:
- Wanneer u een project, oplossing of map opgeeft of als u dit argument weglaat, wordt de aanroep doorgestuurd naar msbuild. In dat geval vindt u de beschikbare argumenten in de dotnet msbuild-documentatie.
- Wanneer u een .dll of een .exe opgeeft, wordt de oproep doorgestuurd naar vstest. In dat geval vindt u de beschikbare argumenten in de dotnet vstest-documentatie.
RunSettings Argumenten

Inline RunSettings wordt doorgegeven als de laatste argumenten op de opdrachtregel na '-- ' (let op de spatie na --). Inline RunSettings wordt opgegeven als [name]=[value] paren. Er wordt een spatie gebruikt om meerdere [name]=[value] paren te scheiden.

Voorbeeld: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

Zie RunSettings-argumenten doorgeven via de opdrachtregel voor meer informatie.

Voorbeelden

Voer de tests uit in het project in de huidige map:
```
dotnet test
```

Voer de tests in het test1 project uit:

dotnet test ~/projects/test1/test1.csproj

Voer de tests uit met behulp van test1.dll assembly:

dotnet test ~/projects/test1/bin/debug/test1.dll

Voer de tests uit in het project in de huidige map en genereer een testresultatenbestand in de trx-indeling:
```
dotnet test --logger trx
```
Voer de tests uit in het project in de huidige map en genereer een codedekkingsbestand met behulp van Microsoft Code Coverage:
```
dotnet test --collect "Code Coverage"
```
Voer de tests uit in het project in de huidige map en genereer een codedekkingsbestand met behulp van Coverlet- (nadat u Coverlet collectors-integratie hebt geïnstalleerd):
```
dotnet test --collect:"XPlat Code Coverage"
```
Voer de tests uit in het project in de huidige map en meld u met gedetailleerde uitgebreidheid aan bij de console:
```
dotnet test --logger "console;verbosity=detailed"
```
Voer de tests uit in het project in de huidige map en meld u aan met de trx-logger om TestResults.trx te testen in de map TestResults :
```
dotnet test --logger "trx;logfilename=testResults.trx"
```
Omdat de naam van het logboekbestand is opgegeven, wordt dezelfde naam gebruikt voor elk doelframework in het geval van een project met meerdere doelen. De uitvoer voor elk doelframework overschrijft de uitvoer voor voorgaande doelframeworks. Het bestand wordt gemaakt in de map TestResults in de map testproject, omdat relatieve paden relatief zijn ten opzichte van die map. In het volgende voorbeeld ziet u hoe u voor elk doelframework een afzonderlijk bestand maakt.
Voer de tests uit in het project in de huidige map en meld u aan met de trx-logger naar bestanden in de map TestResults , met bestandsnamen die uniek zijn voor elk doelframework:
```
dotnet test --logger:"trx;LogFilePrefix=testResults"
```
Voer de tests uit in het project in de huidige map en meld u aan met de HTML-logboekregistratie om te testResults.html in de map TestResults:
```
dotnet test --logger "html;logfilename=testResults.html"
```
Voer de tests uit in het project in de huidige map en meld tests die werden uitgevoerd toen de testhost vastliep:
```
dotnet test --blame
```
Voer de tests in het test1 project uit en geef het -bl argument (binair logboek) op voor msbuild:
```
dotnet test ~/projects/test1/test1.csproj -bl
```
Voer de tests in het test1 project uit en stel de eigenschap MSBuild DefineConstants in op DEV:
```
dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
```
Voer de tests in het test1 project uit en stel de eigenschap MSBuild TestTfmsInParallel in op false:
```
dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
```

--filter <EXPRESSION>

<Expression> heeft de indeling <property><operator><value>[|&<Expression>].

<property> is een kenmerk van de Test Case. Hier volgen de eigenschappen die worden ondersteund door populaire frameworks voor eenheidstests:

Testframework	Ondersteunde eigenschappen
MSTest	FullyQualifiedName Naam KlasseNaam Priority TestCategory
xUnit	FullyQualifiedName Schermnaam Categorie
NUnit	FullyQualifiedName Naam Categorie Priority

Hierin <operator> wordt de relatie tussen de eigenschap en de waarde beschreven:

Operator	Functie
`=`	Exacte overeenkomst
`!=`	Niet exacte overeenkomst
`~`	Bevat
`!~`	Bevat geen

<value> is een tekenreeks. Alle zoekacties zijn hoofdlettergevoelig.

Een expressie zonder een <operator> wordt automatisch beschouwd als een contains on-eigenschap FullyQualifiedName (bijvoorbeeld dotnet test --filter xyz hetzelfde als dotnet test --filter FullyQualifiedName~xyz).

Expressies kunnen worden samengevoegd met voorwaardelijke operators:

Operator	Functie
`\|`	OR
`&`	AND

U kunt expressies tussen haakjes zetten wanneer u voorwaardelijke operatoren gebruikt (bijvoorbeeld (Name~TestMethod1) | (Name~TestMethod2)).

Zie Selectief eenheidstests uitvoeren voor meer informatie en voorbeelden over het gebruik van selectief eenheidstests.

Zie ook

Feedback

Is deze pagina nuttig?

Last updated on 2026-01-06