Automated Testing Strategy - Enterprise Guide 2025

Q: What is the Test Pyramid and why is it important?

The Test Pyramid is a testing strategy showing the optimal proportion of different types of tests. At the base are fast and cheap unit tests (70%), in the middle are integration tests (20%), and at the top are expensive E2E tests (10%). This structure ensures fast feedback, low maintenance costs, and high confidence in code quality.

Q: What's the difference between unit tests and integration tests?

Unit tests check individual components in isolation (functions, classes) with mocked dependencies - they are fast and simple. Integration tests verify how multiple components work together with real dependencies (database, API) - they are slower but catch integration issues.

Q: Should I use Playwright or Cypress for E2E testing?

Playwright is a more modern tool with better support for multiple browsers (Chrome, Firefox, Safari, Edge), faster execution, and the ability to test multiple tabs. Cypress has an easier API and better integration with the JavaScript ecosystem. For new projects, I recommend Playwright.

Q: What should my code coverage target be?

A realistic target is 70-80% code coverage for production code. 100% coverage is inefficient - quality of tests is more important than quantity. Focus on testing business logic, edge cases, and critical paths. Don't test getters/setters or framework code.

Q: How do I integrate tests with CI/CD pipeline?

Run unit tests on every commit, integration tests before merging to main, E2E tests after deploying to staging environment. Use parallel execution for speed. Block merges on failed tests. Generate coverage reports and archive test results. Use GitHub Actions or Azure DevOps for automation.

Every production bug has a cost. According to IBM, fixing a bug in production is up to 100x more expensive than catching it during development. For enterprises where every minute of downtime costs thousands, automated testing isn't optional.

Companies with solid test automation report 90% reduction in testing time, 85% fewer production bugs, and 3x faster time-to-market. How do you get there?

This guide covers Test Pyramid fundamentals, unit testing with xUnit and Jest, integration tests with TestContainers, E2E testing (Playwright vs Cypress), and CI/CD integration. All examples are production-ready code for .NET and JavaScript.

Why automated testing is critical for enterprise

Your team ships a new version. A few hours later, the phone rings. A critical bug is blocking payments. Panic. Rollback. Lost revenue. Angry users.

Manual testing doesn't scale. With hundreds of features and continuous changes, manual QA becomes the bottleneck that slows everything down. Automated testing fixes this.

Business benefits of automated testing:

⚡

Faster time-to-market

Tests run in minutes instead of days. Regression takes seconds, not weeks. Deploying to production 10x per day becomes realistic.

💰

Cost reduction

Catching bugs during development costs 100x less than fixing them in production. Automated tests find issues before code review, saving team time.

🔒

Higher code quality

A test suite acts as a safety net. Refactoring becomes safe, technical debt easier to pay down. And testable code tends to be better-designed code.

📚

Living documentation

Tests show how code actually works, not how someone intended it to work. New developers learn from tests faster than from any wiki page.

🚀

Deployment confidence

With good test coverage, Friday deploys stop being scary. Continuous deployment works because every change is verified automatically.

📊Market data

According to the State of DevOps Report 2024, high-performing teams with comprehensive automated testing have:

• 208x more frequent deployments than low performers
• 106x faster lead time from commit to production
• 7x lower change failure rate
• 2,604x faster mean time to recovery (MTTR)

Test Pyramid - foundation of testing strategy

The Test Pyramid, introduced by Mike Cohn, is a way to balance different types of tests. It shows the proportion of tests that gives you the best ratio of speed to confidence.

The idea is simple: lots of fast unit tests at the bottom, fewer integration tests in the middle, and a small number of slow E2E tests at the top. Each layer has its purpose, but the foundation matters most.

Test Pyramid structure:

🔬Unit Tests (70%)

Base of the pyramid - fast, isolated tests of individual functions/classes. Execute in milliseconds, easy to write and maintain.

Characteristics:

• Test one unit of code (function, method, class)
• All dependencies are mocked
• Execute in < 100ms each
• Should constitute 70% of all tests
• Framework: xUnit (.NET), Jest/Vitest (JS), JUnit (Java)

🔗Integration Tests (20%)

Middle of the pyramid - verify component collaboration with real dependencies (database, external APIs). Slower but catch integration bugs.

Characteristics:

• Test integration of multiple components
• Use real database (TestContainers)
• Execute in seconds
• Should constitute 20% of all tests
• Framework: xUnit + TestContainers (.NET), Jest + Testcontainers (JS)

🌐E2E Tests (10%)

Top of the pyramid - test the entire application like a real user. Slowest and most brittle, but provide highest confidence in user flows.

Characteristics:

• Test complete user journeys (login, checkout, etc.)
• Run real browser
• Execute in minutes
• Should constitute 10% of all tests
• Framework: Playwright, Cypress, Selenium

Why a pyramid, not a diamond or ice cream?

Anti-pattern: Ice Cream Cone - more E2E tests than unit tests. Results in slow build times, flaky tests, and expensive maintenance.

The pyramid is optimal because unit tests are fast (instant feedback), cheap (easy maintenance), and stable (deterministic). E2E tests are slow, expensive, and flaky - use sparingly for critical paths.

Unit testing - xUnit, Jest and best practices

Unit tests are the base of any automated testing strategy. They test individual functions or methods in isolation, which means fast feedback and easy debugging.

They run in milliseconds. They catch bugs instantly. And when something goes wrong, you know exactly where to look. Below are practical examples for .NET (xUnit) and JavaScript (Jest).

🔵xUnit - Unit Testing for .NET

xUnit is the most modern testing framework for .NET, used by Microsoft in ASP.NET Core projects. Simple, extensible, and with great support for parallel execution.

// ProductService.cs - Class to test

public class ProductService
{
    private readonly IProductRepository _repository;

    public ProductService(IProductRepository repository)
    {
        _repository = repository;
    }

    public async Task<Product> GetProductById(int id)
    {
        if (id <= 0)
            throw new ArgumentException("Product ID must be positive");

        var product = await _repository.GetByIdAsync(id);

        if (product == null)
            throw new NotFoundException($"Product {id} not found");

        return product;
    }
}

// ProductServiceTests.cs - Unit Tests

public class ProductServiceTests
{
    private readonly Mock<IProductRepository> _mockRepository;
    private readonly ProductService _service;

    public ProductServiceTests()
    {
        _mockRepository = new Mock<IProductRepository>();
        _service = new ProductService(_mockRepository.Object);
    }

    [Fact]
    public async Task GetProductById_ValidId_ReturnsProduct()
    {
        // Arrange
        var expectedProduct = new Product { Id = 1, Name = "Test" };
        _mockRepository
            .Setup(r => r.GetByIdAsync(1))
            .ReturnsAsync(expectedProduct);

        // Act
        var result = await _service.GetProductById(1);

        // Assert
        Assert.Equal(expectedProduct, result);
        _mockRepository.Verify(r => r.GetByIdAsync(1), Times.Once);
    }

    [Theory]
    [InlineData(0)]
    [InlineData(-1)]
    public async Task GetProductById_InvalidId_ThrowsException(int id)
    {
        // Act & Assert
        await Assert.ThrowsAsync<ArgumentException>(
            () => _service.GetProductById(id)
        );
    }

    [Fact]
    public async Task GetProductById_NotFound_ThrowsNotFoundException()
    {
        // Arrange
        _mockRepository
            .Setup(r => r.GetByIdAsync(999))
            .ReturnsAsync((Product)null);

        // Act & Assert
        var exception = await Assert.ThrowsAsync<NotFoundException>(
            () => _service.GetProductById(999)
        );
        Assert.Contains("999", exception.Message);
    }
}

Key NuGet packages:

• xunit (test framework)
• xunit.runner.visualstudio (VS integration)
• Moq (mocking library)
• FluentAssertions (readable assertions)
• Bogus (fake data generation)

🟡Jest - Unit Testing for JavaScript/TypeScript

Jest is the most popular testing framework for JavaScript, created by Facebook. Zero config, built-in mocking, code coverage, and great developer experience.

// productService.ts - Service to test

export class ProductService {
  constructor(private repository: ProductRepository) {}

  async getProductById(id: number): Promise<Product> {
    if (id <= 0) {
      throw new Error('Product ID must be positive');
    }

    const product = await this.repository.getById(id);

    if (!product) {
      throw new Error(`Product ${id} not found`);
    }

    return product;
  }

  async calculateDiscount(product: Product, code: string): Promise<number> {
    const discount = await this.repository.getDiscountByCode(code);
    return product.price * (discount / 100);
  }
}

// productService.test.ts - Unit Tests

import { ProductService } from './productService';
import { ProductRepository } from './productRepository';

jest.mock('./productRepository');

describe('ProductService', () => {
  let service: ProductService;
  let mockRepository: jest.Mocked<ProductRepository>;

  beforeEach(() => {
    mockRepository = new ProductRepository() as jest.Mocked<ProductRepository>;
    service = new ProductService(mockRepository);
  });

  describe('getProductById', () => {
    it('should return product when valid ID is provided', async () => {
      // Arrange
      const mockProduct = { id: 1, name: 'Test Product', price: 100 };
      mockRepository.getById.mockResolvedValue(mockProduct);

      // Act
      const result = await service.getProductById(1);

      // Assert
      expect(result).toEqual(mockProduct);
      expect(mockRepository.getById).toHaveBeenCalledWith(1);
      expect(mockRepository.getById).toHaveBeenCalledTimes(1);
    });

    it.each([0, -1, -99])(
      'should throw error when ID is %i',
      async (invalidId) => {
        await expect(service.getProductById(invalidId))
          .rejects
          .toThrow('Product ID must be positive');
      }
    );

    it('should throw error when product not found', async () => {
      mockRepository.getById.mockResolvedValue(null);

      await expect(service.getProductById(999))
        .rejects
        .toThrow('Product 999 not found');
    });
  });

  describe('calculateDiscount', () => {
    it('should calculate correct discount amount', async () => {
      const product = { id: 1, name: 'Test', price: 100 };
      mockRepository.getDiscountByCode.mockResolvedValue(20);

      const discount = await service.calculateDiscount(product, 'SAVE20');

      expect(discount).toBe(20);
    });
  });
});

Key npm packages:

• jest (test framework)
• @types/jest (TypeScript types)
• ts-jest (TypeScript transformer)
• @testing-library/react (React testing)
• jest-mock-extended (advanced mocking)

✅Best practices for unit testing

AAA Pattern (Arrange-Act-Assert) - structure tests in three sections for readability
One Assert Per Test - each test should verify one thing (easier debugging)
Name tests descriptively - GetProductById_InvalidId_ThrowsException instead of Test1
Test edge cases - null, empty, negative, boundary values
Don't test implementation - test behavior, not internal details (avoid over-mocking)
Speed matters - unit tests should execute in < 100ms each

Integration testing with TestContainers

Integration tests verify how components work together with real dependencies - databases, message queues, cache, external APIs.

The hard part: how do you test against a real PostgreSQL database without installing it on every developer machine? TestContainers solves this by running real services in Docker containers during tests and automatically cleaning them up.

Why TestContainers?

Traditional approach: In-memory databases (SQLite, H2), mocked services. Problem: don't test real behavior (SQL dialect differences, network issues, version mismatches).

TestContainers approach: Runs real services (PostgreSQL, Redis, RabbitMQ) in Docker containers for each test suite. Tests execute against real infrastructure, then containers are automatically removed.

• Real services - test against production-like environment
• Isolation - each test suite gets a fresh container
• Clean up - containers automatically removed after tests
• Reproducible - consistent results on dev/CI

Integration Test with PostgreSQL (.NET + Testcontainers)

using Testcontainers.PostgreSql;
using Xunit;

public class ProductRepositoryIntegrationTests : IAsyncLifetime
{
    private readonly PostgreSqlContainer _postgres;
    private ProductDbContext _dbContext;
    private ProductRepository _repository;

    public ProductRepositoryIntegrationTests()
    {
        _postgres = new PostgreSqlBuilder()
            .WithImage("postgres:15-alpine")
            .WithDatabase("testdb")
            .WithUsername("test")
            .WithPassword("test")
            .Build();
    }

    public async Task InitializeAsync()
    {
        // Start container
        await _postgres.StartAsync();

        // Setup DbContext with real PostgreSQL
        var options = new DbContextOptionsBuilder<ProductDbContext>()
            .UseNpgsql(_postgres.GetConnectionString())
            .Options;

        _dbContext = new ProductDbContext(options);
        await _dbContext.Database.MigrateAsync(); // Run migrations

        _repository = new ProductRepository(_dbContext);
    }

    [Fact]
    public async Task CreateProduct_ShouldPersistToDatabase()
    {
        // Arrange
        var product = new Product
        {
            Name = "Integration Test Product",
            Price = 99.99m
        };

        // Act
        var created = await _repository.CreateAsync(product);

        // Assert
        var fromDb = await _repository.GetByIdAsync(created.Id);
        Assert.NotNull(fromDb);
        Assert.Equal("Integration Test Product", fromDb.Name);
        Assert.Equal(99.99m, fromDb.Price);
    }

    [Fact]
    public async Task GetProductsByCategory_ShouldReturnFilteredResults()
    {
        // Arrange - seed test data
        await _repository.CreateAsync(new Product { Name = "Laptop", Category = "Electronics" });
        await _repository.CreateAsync(new Product { Name = "Phone", Category = "Electronics" });
        await _repository.CreateAsync(new Product { Name = "Shirt", Category = "Clothing" });

        // Act
        var electronics = await _repository.GetByCategoryAsync("Electronics");

        // Assert
        Assert.Equal(2, electronics.Count());
        Assert.All(electronics, p => Assert.Equal("Electronics", p.Category));
    }

    public async Task DisposeAsync()
    {
        await _dbContext.DisposeAsync();
        await _postgres.DisposeAsync(); // Stop and remove container
    }
}

Integration Test with MongoDB (Node.js + Testcontainers)

import { GenericContainer, StartedTestContainer } from 'testcontainers';
import { MongoClient, Db } from 'mongodb';
import { ProductRepository } from './productRepository';

describe('ProductRepository Integration Tests', () => {
  let container: StartedTestContainer;
  let client: MongoClient;
  let db: Db;
  let repository: ProductRepository;

  beforeAll(async () => {
    // Start MongoDB container
    container = await new GenericContainer('mongo:7.0')
      .withExposedPorts(27017)
      .start();

    const uri = `mongodb://${container.getHost()}:${container.getMappedPort(27017)}`;
    client = await MongoClient.connect(uri);
    db = client.db('test');

    repository = new ProductRepository(db);
  }, 60000); // timeout for container startup

  afterAll(async () => {
    await client.close();
    await container.stop();
  });

  beforeEach(async () => {
    // Clean database before each test
    await db.collection('products').deleteMany({});
  });

  it('should create and retrieve product', async () => {
    // Arrange
    const product = {
      name: 'Test Product',
      price: 29.99,
      stock: 100
    };

    // Act
    const created = await repository.create(product);
    const retrieved = await repository.findById(created._id);

    // Assert
    expect(retrieved).toBeDefined();
    expect(retrieved?.name).toBe('Test Product');
    expect(retrieved?.price).toBe(29.99);
  });

  it('should handle concurrent writes correctly', async () => {
    // Test race conditions and transactions
    const promises = Array.from({ length: 10 }, (_, i) =>
      repository.create({ name: `Product ${i}`, price: i * 10 })
    );

    await Promise.all(promises);

    const count = await repository.count();
    expect(count).toBe(10);
  });
});

When to use Integration Tests?

• Database queries - complex JOINs, full-text search, transactions
• External API integrations - payment gateways, email providers
• Message queues - RabbitMQ, Kafka, Azure Service Bus
• Cache behavior - Redis, Memcached invalidation logic
• File storage - S3, Azure Blob, filesystem operations

E2E testing - Playwright vs Cypress

E2E (End-to-End) tests simulate a real user: they launch a browser, click buttons, fill forms, and verify results. These are the most expensive tests to maintain, but they provide the highest confidence that the application works from start to finish.

Playwright or Cypress? Both are good, but they have different strengths. Here is a detailed comparison.

🎭Playwright

Created by Microsoft, the most modern E2E testing tool. Multi-browser support (Chrome, Firefox, Safari, Edge), fast execution, and auto-waiting.

✓ Pros:

• All browsers (Chrome, Firefox, Safari, Edge)
• Faster execution than Cypress (true parallelization)
• Testing multiple tabs and contexts
• Auto-waiting (no flaky tests)
• Network interception and API mocking
• Built-in test generator (Codegen)

✗ Cons:

• Younger tool (fewer resources)
• Fewer plugins than Cypress

🌲Cypress

First popular E2E framework for JavaScript. Great developer experience, time-travel debugging, and rich plugin ecosystem.

✓ Pros:

• Easy API (jQuery-like selectors)
• Great debugging (time travel, screenshots)
• Rich plugin ecosystem
• Visual test runner (watch mode)
• Automatic retries and waiting

✗ Cons:

• Chrome + Firefox only (no Safari)
• Slower (tests run serially in open source)
• Doesn't support multi-tab scenarios
• Same-origin limitation

Example: E2E Test with Playwright

import { test, expect } from '@playwright/test';

test.describe('E-commerce Checkout Flow', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('https://example.com');
  });

  test('user can complete purchase', async ({ page }) => {
    // 1. Search for product
    await page.getByPlaceholder('Search products').fill('laptop');
    await page.getByRole('button', { name: 'Search' }).click();

    // 2. Select product from results
    await expect(page.getByText('Gaming Laptop')).toBeVisible();
    await page.getByText('Gaming Laptop').click();

    // 3. Add to cart
    await expect(page.getByRole('heading', { name: 'Gaming Laptop' })).toBeVisible();
    await page.getByRole('button', { name: 'Add to Cart' }).click();

    // 4. Verify cart badge updated
    await expect(page.getByTestId('cart-badge')).toHaveText('1');

    // 5. Go to checkout
    await page.getByRole('button', { name: 'Cart' }).click();
    await page.getByRole('button', { name: 'Checkout' }).click();

    // 6. Fill shipping information
    await page.getByLabel('Full Name').fill('John Doe');
    await page.getByLabel('Email').fill('john@example.com');
    await page.getByLabel('Address').fill('123 Main St');
    await page.getByLabel('City').fill('New York');
    await page.getByLabel('ZIP').fill('10001');

    // 7. Select payment method
    await page.getByRole('radio', { name: 'Credit Card' }).check();
    await page.getByLabel('Card Number').fill('4242424242424242');
    await page.getByLabel('Expiry').fill('12/25');
    await page.getByLabel('CVV').fill('123');

    // 8. Submit order
    await page.getByRole('button', { name: 'Place Order' }).click();

    // 9. Verify order confirmation
    await expect(page.getByRole('heading', { name: 'Order Confirmed!' })).toBeVisible();
    await expect(page.getByText(/Order #/)).toBeVisible();

    // 10. Screenshot for visual verification
    await page.screenshot({ path: 'order-confirmation.png' });
  });

  test('validates required fields', async ({ page }) => {
    await page.goto('/checkout');
    await page.getByRole('button', { name: 'Place Order' }).click();

    // Should show validation errors
    await expect(page.getByText('Name is required')).toBeVisible();
    await expect(page.getByText('Email is required')).toBeVisible();
  });

  test('handles out of stock items', async ({ page }) => {
    // Intercept API and mock out of stock response
    await page.route('**/api/products/*', route => {
      route.fulfill({
        status: 200,
        body: JSON.stringify({ stock: 0, available: false })
      });
    });

    await page.goto('/product/123');
    await expect(page.getByText('Out of Stock')).toBeVisible();
    await expect(page.getByRole('button', { name: 'Add to Cart' })).toBeDisabled();
  });
});

Example: E2E Test with Cypress

describe('User Authentication Flow', () => {
  beforeEach(() => {
    cy.visit('/login');
  });

  it('allows user to login with valid credentials', () => {
    // Fill login form
    cy.get('[data-cy=email-input]').type('user@example.com');
    cy.get('[data-cy=password-input]').type('SecurePassword123!');
    cy.get('[data-cy=login-button]').click();

    // Verify redirect to dashboard
    cy.url().should('include', '/dashboard');
    cy.get('[data-cy=welcome-message]')
      .should('contain', 'Welcome back, User!');

    // Verify auth token stored
    cy.window().its('localStorage.authToken').should('exist');
  });

  it('shows error for invalid credentials', () => {
    cy.get('[data-cy=email-input]').type('wrong@example.com');
    cy.get('[data-cy=password-input]').type('wrongpassword');
    cy.get('[data-cy=login-button]').click();

    // Should show error message
    cy.get('[data-cy=error-message]')
      .should('be.visible')
      .and('contain', 'Invalid credentials');

    // Should not redirect
    cy.url().should('include', '/login');
  });

  it('supports password reset flow', () => {
    cy.get('[data-cy=forgot-password]').click();
    cy.url().should('include', '/reset-password');

    // Enter email
    cy.get('[data-cy=email-input]').type('user@example.com');
    cy.get('[data-cy=send-reset-button]').click();

    // Verify success message
    cy.get('[data-cy=success-message]')
      .should('contain', 'Reset link sent to your email');
  });

  it('persists authentication across page reloads', () => {
    // Login
    cy.get('[data-cy=email-input]').type('user@example.com');
    cy.get('[data-cy=password-input]').type('SecurePassword123!');
    cy.get('[data-cy=login-button]').click();

    // Reload page
    cy.reload();

    // Should still be authenticated
    cy.url().should('include', '/dashboard');
    cy.get('[data-cy=logout-button]').should('be.visible');
  });
});

Playwright vs Cypress - Which to choose?

Choose Playwright if: you need multi-browser support (Safari testing), faster execution (parallel testing), or test advanced scenarios (multiple tabs, contexts, iframes).

Choose Cypress if: your team prefers simpler API, needs rich plugin ecosystem, or already uses Cypress (migration not always worth the effort). Cypress is still a solid choice.

2025 Recommendation: For new projects, choose Playwright. It has better support for modern applications, faster execution, and active development by Microsoft.

Test integration with CI/CD pipeline

Have great tests? Excellent. But if they don't run automatically on every push, it's like they don't exist.

CI/CD integration makes this real. Every commit triggers tests. Every failed test blocks the merge. No bug reaches production undetected. Below are examples for GitHub Actions and Azure DevOps.

💡 Useful resources:

→ GitHub Actions vs Azure DevOps - Which to Choose?→ Azure DevOps Best Practices 2025

⚙️GitHub Actions - Complete Testing Pipeline

.github/workflows/test.yml

name: Test Pipeline

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

jobs:
  unit-tests:
    name: Unit Tests
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run unit tests
        run: npm run test:unit -- --coverage

      - name: Upload coverage to Codecov
        uses: codecov/codecov-action@v3
        with:
          files: ./coverage/lcov.info
          flags: unit

  integration-tests:
    name: Integration Tests
    runs-on: ubuntu-latest
    needs: unit-tests

    services:
      postgres:
        image: postgres:15-alpine
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: testdb
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20.x
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run database migrations
        run: npm run db:migrate
        env:
          DATABASE_URL: postgresql://postgres:test@localhost:5432/testdb

      - name: Run integration tests
        run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:test@localhost:5432/testdb

  e2e-tests:
    name: E2E Tests
    runs-on: ubuntu-latest
    needs: integration-tests

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20.x
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright browsers
        run: npx playwright install --with-deps

      - name: Build application
        run: npm run build

      - name: Run E2E tests
        run: npm run test:e2e

      - name: Upload test results
        uses: actions/upload-artifact@v3
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

🔷Azure DevOps - .NET Testing Pipeline

azure-pipelines.yml

trigger:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'
  dotnetVersion: '8.x'

stages:
  - stage: Test
    displayName: 'Run All Tests'
    jobs:
      - job: UnitTests
        displayName: 'Unit Tests'
        steps:
          - task: UseDotNet@2
            inputs:
              version: $(dotnetVersion)

          - task: DotNetCoreCLI@2
            displayName: 'Restore packages'
            inputs:
              command: 'restore'
              projects: '**/*.csproj'

          - task: DotNetCoreCLI@2
            displayName: 'Build solution'
            inputs:
              command: 'build'
              arguments: '--configuration $(buildConfiguration)'

          - task: DotNetCoreCLI@2
            displayName: 'Run unit tests'
            inputs:
              command: 'test'
              projects: '**/*UnitTests.csproj'
              arguments: >
                --configuration $(buildConfiguration)
                --collect:"XPlat Code Coverage"
                --logger trx
                --results-directory $(Agent.TempDirectory)

          - task: PublishTestResults@2
            displayName: 'Publish test results'
            inputs:
              testResultsFormat: 'VSTest'
              testResultsFiles: '**/*.trx'
              searchFolder: '$(Agent.TempDirectory)'

          - task: PublishCodeCoverageResults@2
            displayName: 'Publish coverage'
            inputs:
              codeCoverageTool: 'Cobertura'
              summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

      - job: IntegrationTests
        displayName: 'Integration Tests'
        dependsOn: UnitTests
        services:
          postgres:
            image: postgres:15-alpine
            ports:
              - 5432:5432
            env:
              POSTGRES_PASSWORD: test
              POSTGRES_DB: testdb

        steps:
          - task: UseDotNet@2
            inputs:
              version: $(dotnetVersion)

          - task: DotNetCoreCLI@2
            displayName: 'Run integration tests'
            inputs:
              command: 'test'
              projects: '**/*IntegrationTests.csproj'
              arguments: >
                --configuration $(buildConfiguration)
                --logger trx
            env:
              ConnectionStrings__DefaultConnection: 'Host=localhost;Database=testdb;Username=postgres;Password=test'

      - job: E2ETests
        displayName: 'E2E Tests'
        dependsOn: IntegrationTests

        steps:
          - task: UseDotNet@2
            inputs:
              version: $(dotnetVersion)

          - script: |
              npx playwright install --with-deps
            displayName: 'Install Playwright'

          - task: DotNetCoreCLI@2
            displayName: 'Build and run app'
            inputs:
              command: 'run'
              projects: '**/MyApp.csproj'
            env:
              ASPNETCORE_ENVIRONMENT: 'Test'

          - script: |
              npm run test:e2e
            displayName: 'Run E2E tests'

          - task: PublishPipelineArtifact@1
            condition: always()
            inputs:
              targetPath: 'playwright-report'
              artifact: 'e2e-test-report'

✅CI/CD testing best practices

Fail Fast - run unit tests first (fast), integration and E2E later. Stop pipeline on first failure.
Parallel Execution - run tests in parallel for speed (matrix builds, sharding)
Test Environment Parity - CI environment should be identical to production (same versions, configs)
Artifact Storage - store test reports, screenshots, videos for debugging
Coverage Gates - block merge if coverage drops below threshold (e.g., 70%)
Notifications - alert team about failed builds (Slack, Teams, email)

Code coverage and quality metrics

Code coverage is the percentage of code executed by tests. A common question: "How much coverage is good coverage?"

The answer isn't simple. High coverage doesn't guarantee test quality, but low coverage definitely signals a problem. Here are the key metrics and how to read them.

Code Coverage for .NET

# Generate coverage report
dotnet test --collect:"XPlat Code Coverage"

# Generate HTML report with coverlet
dotnet test /p:CollectCoverage=true /p:CoverageReportFormat=html

# Use ReportGenerator for beautiful reports
dotnet tool install -g dotnet-reportgenerator-globaltool
reportgenerator \
  -reports:"**/coverage.cobertura.xml" \
  -targetdir:"coveragereport" \
  -reporttypes:Html

Packages: coverlet.collector, ReportGenerator

Code Coverage for JavaScript

// package.json
{
  "scripts": {
    "test": "jest --coverage",
    "test:watch": "jest --watch --coverage"
  }
}

// jest.config.js
module.exports = {
  collectCoverageFrom: [
    'src/**/*.{js,ts,tsx}',
    '!src/**/*.test.{js,ts,tsx}',
    '!src/**/*.d.ts'
  ],
  coverageThresholds: {
    global: {
      branches: 70,
      functions: 70,
      lines: 70,
      statements: 70
    }
  }
};

Tools: Jest (built-in), Istanbul, nyc

Key coverage metrics:

📊

Line Coverage

Percentage of code lines executed by tests. Most basic metric. Target: 70-80%

🔀

Branch Coverage

Percentage of branches (if/else, switch) tested. More important than line coverage for business logic. Target: 70%+

⚙️

Function Coverage

Percentage of functions/methods called by tests. Identifies dead code and unused methods.

📝

Statement Coverage

Percentage of statements executed. Similar to line coverage but more granular.

Coverage is not a goal in itself

100% coverage ≠ zero bugs. You can have 100% coverage with tests that verify nothing. Example: a test that calls a function but doesn't check the result.

Focus on quality, not quantity. Better to have 70% coverage with solid tests verifying edge cases than 95% with superficial tests.

Test behavior, not implementation. Coverage shows WHAT is tested, but not HOW. Test public APIs and business logic, not internal details.

Realistic target for enterprise: 70-80% line coverage, 70%+ branch coverage. Prioritize testing: business logic, edge cases, error handling, security-critical code.

Frequently asked questions

What is the Test Pyramid and why is it important?

The Test Pyramid is a testing strategy showing the optimal proportion of different types of tests. At the base are fast and cheap unit tests (70%), in the middle are integration tests (20%), and at the top are expensive E2E tests (10%). This structure ensures fast feedback, low maintenance costs, and high confidence in code quality.

What's the difference between unit tests and integration tests?

Unit tests check individual components in isolation (functions, classes) with mocked dependencies - they are fast and simple. Integration tests verify how multiple components work together with real dependencies (database, API) - they are slower but catch integration issues.

Should I use Playwright or Cypress for E2E testing?

Playwright is a more modern tool with better support for multiple browsers (Chrome, Firefox, Safari, Edge), faster execution, and the ability to test multiple tabs. Cypress has an easier API and better integration with the JavaScript ecosystem. For new projects, I recommend Playwright.

What should my code coverage target be?

A realistic target is 70-80% code coverage for production code. 100% coverage is inefficient - quality of tests is more important than quantity. Focus on testing business logic, edge cases, and critical paths. Don't test getters/setters or framework code.

How do I integrate tests with CI/CD pipeline?

Run unit tests on every commit, integration tests before merging to main, E2E tests after deploying to staging environment. Use parallel execution for speed. Block merges on failed tests. Generate coverage reports and archive test results. Use GitHub Actions or Azure DevOps for automation.

Want to implement automated testing in your company?

A testing strategy is as much about team habits as it is about code. I can help you through the entire process:

✓ Audit existing tests and code coverage analysis
✓ Test Pyramid implementation (unit, integration, E2E)
✓ CI/CD integration with GitHub Actions or Azure DevOps
✓ Team training and best practices workshops
✓ Monitoring, metrics, and continuous improvement

Want fewer production bugs? Let's talk about your project.

Schedule Free Consultation View Portfolio

Why automated testing is critical for enterprise

Business benefits of automated testing:

📊Market data

Test Pyramid - foundation of testing strategy

Test Pyramid structure:

🔬Unit Tests (70%)

🔗Integration Tests (20%)

🌐E2E Tests (10%)

Why a pyramid, not a diamond or ice cream?

Unit testing - xUnit, Jest and best practices

🔵xUnit - Unit Testing for .NET

🟡Jest - Unit Testing for JavaScript/TypeScript

✅Best practices for unit testing

Integration testing with TestContainers

Why TestContainers?

Integration Test with PostgreSQL (.NET + Testcontainers)

Integration Test with MongoDB (Node.js + Testcontainers)

When to use Integration Tests?

E2E testing - Playwright vs Cypress

🎭Playwright

🌲Cypress

Example: E2E Test with Playwright

Example: E2E Test with Cypress

Playwright vs Cypress - Which to choose?

Test integration with CI/CD pipeline

⚙️GitHub Actions - Complete Testing Pipeline

🔷Azure DevOps - .NET Testing Pipeline

✅CI/CD testing best practices

Code coverage and quality metrics

Code Coverage for .NET

Code Coverage for JavaScript

Key coverage metrics:

Coverage is not a goal in itself

Frequently asked questions

What is the Test Pyramid and why is it important?

What's the difference between unit tests and integration tests?

Should I use Playwright or Cypress for E2E testing?

What should my code coverage target be?

How do I integrate tests with CI/CD pipeline?

Related articles

Azure DevOps Best Practices 2025

Complete Next.js 15 Guide

API and Integrations for Enterprise

Want to implement automated testing in your company?