Build and Test Stages

The build and test stages are the part of the pipeline that answers one question: does this change work? Everything later in the pipeline — packaging, deploying, promoting — depends on that answer being trustworthy.

Two properties make it trustworthy. The run has to be repeatable, meaning the same commit produces the same result on a machine that has never seen your project. And it has to fail, loudly and immediately, when something is wrong. A pipeline that reports success on a broken commit is worse than no pipeline, because people act on it.

name: employees-api-ci

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 8.0.x
          cache: true
          cache-dependency-path: "**/packages.lock.json"

      - name: Restore
        run: dotnet restore --locked-mode

      - name: Build once
        run: dotnet build --no-restore --configuration Release -warnaserror

      - name: Fast tests
        run: dotnet test tests/Employees.UnitTests --no-build --configuration Release

      - name: Slow tests
        run: dotnet test tests/Employees.IntegrationTests --no-build --configuration Release

      - name: Keep the test results even on failure
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: "**/*.trx"

• Running on both push to main and pull_request means a change is verified before it merges and again after. Verifying only after the merge lets the shared branch break first, which blocks everyone else.
• Caching is keyed on the lock file, so a dependency change invalidates it automatically. Cache the package downloads and nothing else — caching build output is how a pipeline ends up testing binaries from a previous commit, and that failure is extremely hard to diagnose.
• --locked-mode makes the restore fail if the lock file does not match the project files. Without it, a dependency can resolve to a newer version in the pipeline than the one you tested against, and the difference shows up as a mystery.
• The build happens once and both test steps pass --no-build. They run against the same binaries, which removes a whole class of the works-in-one-step-not-the-other problem.
• Fast tests are a separate step before the slow ones, so a broken unit test fails the job in under a minute instead of after the integration suite has finished starting containers. Reordering costs nothing and is usually the largest single improvement to feedback time.
• if: always() on the upload is what makes results available for the run that failed. Steps after a failure are skipped by default, so without it you get reports only for the runs you did not need them for. The timeout kills a hung test rather than letting it hold a runner for hours.
• Azure Pipelines expresses the same job with trigger and pr blocks, a Cache task keyed on the lock file, and a publish-test-results task with an always condition. The names differ; the ordering and the reasoning transfer unchanged.

[Trait("Category", "Integration")]
public class EmployeeSearchTests : IClassFixture<PostgresContainerFixture>
{
    private readonly EmployeesContext _db;

    public EmployeeSearchTests(PostgresContainerFixture fixture) => _db = fixture.Context;

    [Fact]
    public async Task Search_matches_partial_surname()
    {
        var results = await _db.Employees
            .Where(e => e.Surname.StartsWith("Whit"))
            .ToListAsync();

        Assert.Contains(results, e => e.Surname == "Whitfield");
    }
}

• The trait is metadata the test runner can filter on: dotnet test --filter Category!=Integration for the fast pass, and the inverse for the slow one. Use this when fast and slow tests share a project.
• Separate projects, as in the pipeline above, are the simpler split and are worth preferring for a new codebase. The filter approach exists because most codebases did not start that way, and moving files is a bigger change than adding an attribute.
• The fixture starts a real database in a container for the test class. That is what makes this test slow and what makes it worth having — a partial-match query is exactly the kind of thing an in-memory substitute gets wrong, because it does not implement the same string comparison rules.
• Each test class gets its own fixture instance, so classes do not share state through the database. Tests that share one database and run in parallel interfere with each other, and the resulting failures look exactly like flakiness.