GitXplorerGitXplorer
d

scenario-tests

public
6 stars
11 forks
15 issues

Commits

List of commits on branch main.
Verified
87a8742f1ee9a3665a2532af029a6ecbfc0c4fdf

[main] Update dependencies from dotnet/arcade (#178)

ddotnet-maestro[bot] committed a day ago
Verified
3d8777fd6429d42a14c4b8ae2ce6cae6460efe1c

[main] Update dependencies from dotnet/arcade, dotnet/source-build-reference-packages (#175)

ddotnet-maestro[bot] committed 2 days ago
Verified
b52c79b52b0ab0bf4fb79a5a07d3bd7d2552d29f

Update SampleProject to use net10.0 (#177)

ttmds committed 2 days ago
Verified
cf08dbda3908b20b80ceb161d883cc39029d95b6

[main] Update dependencies from dotnet/source-build-reference-packages (#174)

ddotnet-maestro[bot] committed 3 days ago
Verified
a8f73c9f5e535452b38124866c2f6c1be33d2c1b

[main] Update dependencies from dotnet/source-build-externals, dotnet/source-build-reference-packages (#173)

ddotnet-maestro[bot] committed 4 days ago
Verified
b0ca06c74fb2db943320377dd42a43b114b2e983

[main] Update dependencies from dotnet/arcade (#172)

ddotnet-maestro[bot] committed 6 days ago

README

The README file for this repository.

Scenario Tests

This repository contains a basic test harness and set of scenario tests designed to execute on an installed .NET SDK. 'Installed' might mean an extracted .NET SDK archive, or a .NET SDK,installed from an msi, pkg, deb package, etc. The goal is to provide a set of tests which are independent of development repository assumptions or restrictions, and which exercise large swaths of product functionality.

Design and Organization

The scenario tests should be testing an installed SDK. Because this SDK and associated runtime may have issues, it's important to be able to divorce the execution of the test harness from the SDK and runtime being tested. To achieve this, the harness is designed to be a self-discovering executable, which can optionally be deployed as a self-contained application where necessary. Furthermore, the tests themselves execute commands in separate processes from the harness itself.

Let's look at an example. Consider a test that should verify that "dotnet new console" works properly. The executable would contain a test method which would create a new process, running dotnet with parameters new console --name myapp. In the psuedocode example below, VerifyConsoleTemplate is running within the host runtime (either a self-contained or framework dependent deployment), launching processes against

// This method runs on the host runtime
[Fact]
public void VerifyConsoleTemplate()
{
    // Execute the "dotnet" executable in TestTargetSdkDirectory with parameters "new console --name myapp".
    // Working directory is TestTempDirectory
    LaunchProcess(Path.Combine(Test.TestTargetSdkDirectory, "dotnet"), "new console --name myapp", Test.TestTempDirectory)

    VerifyOutput(Path.Combine(Test.TestTempDirectory, "myapp"));
}

Organization

The repository is organized as a set of executable projects and a folder of common utilities/files, which also contains the test harness entry point. The test harness entry point is automatically included in each test project.

Scenario tests for logically different target areas should exist in separate projects.

Build and Executing the Tests

The tests can be built with ./build.sh and ./build.cmd from the root of the repo, or with dotnet build.

Once built, a test project can be executed in the following way:

dotnet <test dll> --dotnet-root <root of SDK installation>

Optionally, for SxS SDK installations, a -sdk-version option may be used to override the default SDK version targeted for testing.

For other options, see the help of the scenario test harness:

dotnet <test dll> --help