AZ-400 Question 111
Single answerYou are designing an Azure Pipelines process for a microservices application based on .NET. The organization requires that both unit tests and integration tests run automatically for every commit. The pipeline should fail if any test fails or if code coverage falls below a specified threshold. You also want to store test results for future analysis. Which approach best meets these requirements?
- A
Configure separate stages for both unit and integration tests in the YAML pipeline, use tasks like 'DotNetCoreCLI@2' for test execution, publish results with 'PublishTestResults@2', and configure coverage thresholds in the pipeline settings.
- B
Run unit tests locally only, push code to Git, and rely on manual QA for integration testing before production deployment.
- C
Use a single pipeline that only runs integration tests, and enable code coverage reporting in the Test Plans interface without setting any thresholds.
- D
Skip test tasks in the continuous integration pipeline, but enable automated tests in a separate release pipeline after deployment to the production environment.
Show answer and explanation
Correct answer: A
Explanation
Enforcing a testing strategy involves integrating test tasks�both unit and integration�directly into the CI pipeline, publishing test results for traceability, and setting coverage thresholds to ensure quality. Azure Pipelines provides tasks like 'DotNetCoreCLI@2' for running tests and 'PublishTestResults@2' to visualize results and coverage. According to Microsoft� best practices, tests should be executed as early as possible in the development lifecycle, and failing test or coverage checks should block further deployment. More information can be found in the Azure DevOps documentation on 'Testing in your pipeline': https://docs.microsoft.com/azure/devops/pipelines/test
- A. Correct.
Correct: Splitting tests into stages (unit and integration) and publishing results in Azure Pipelines ensures tests run automatically for every commit. Code coverage thresholds can be configured within Azure Pipelines to fail the build if coverage is too low. This approach meets the requirement for continuous, automated validation of code quality.
- B. Incorrect.
Incorrect: Relying solely on local unit testing and manual QA for integration tests does not meet the requirement of automatic test execution upon every commit, nor does it enforce coverage thresholds.
- C. Incorrect.
Incorrect: Running only integration tests misses the important step of unit tests for early defect detection. Additionally, while the Test Plans feature can view test outcomes, you need to explicitly configure tasks to enforce code coverage thresholds in the pipeline, not just rely on Test Plans.
- D. Incorrect.
Incorrect: Deferring automated tests to a release pipeline after production deployment is too late to catch critical issues. This approach does not prevent failed code from being deployed, violating the organization's requirement to fail the pipeline on insufficient coverage or failing tests.