- Click details to see more information about the failing run.
- Click on the number of errors and warnings to open Azure DevOps.
- Click on the Tests tabs to see a list of failing tests.
- Expand each run to see which tests failed.
- Open https://github.com/dotnet/roslyn/issues
- Enter the name of the failing test and search for open issues that match the failure.
- Open the Screenshot artifacts for one of the test runs.
- Focus on the first reported integration test failure. Often these failures cascade and it can be misleading.
- Create a new issue and include the failed test name in the title
- Good information to include in the issue body:
- A link to the Azure DevOps tests results.
- Which attempt the failure occurred on.
- Which test run failed.
- Additional details outlined below.
- First check to see if a new entry appears in the *.DotNet.log file for the test. There is a MissingMethodException thrown at the beginning of every test run that will log to *.DotNet.log anything thrown by a previous test run.
If the file is new for the test you are creating (check file timestamp compared to when your tests ran) or contains a different exception than the one given in the MissingMethodException entry, then treat the root cause of the test failure as whatever that exception is.
- If the screenshot shows an interesting state (OS window, etc.), or if the failure is not identified by (2), make sure to include a screenshot from the time of failure in the issue.
- If the cause is not identified by (2), include the stack trace from the TargetInvocationException leading to the test failure.
- Add them to the Flaky Tests columns in the Test Improvements project
Here is an example from a test failure on Jenkins - it's reviewable even though the CI link is broken #26041
-
Failure during Checkout because of locked file
[error] One or more errors occurred. (The process cannot access the file '...\Some.File' because it is being used by another process.)
-
ServiceHub crash
If you see integration tests failing for your PR with screenshots that show info-bar like so:
This means the ServiceHub process crashed. Check the ServiceHub logs to see why. They are available in the log artifacts: