Введение

Аннотация. Разработка современного программного обеспечения на платформе .NET невозможна без надежной стратегии тестирования и отладки. Данный курс посвящен практическим аспектам обеспечения качества кода, начиная с написания модульных и интеграционных тестов с использованием фреймворков xUnit и NUnit и заканчивая глубокой отладкой с помощью WinDbg. Мы рассмотрим не только теорию, но и реальные сценарии, включая использование библиотеки Moq для изоляции зависимостей и методологию TDD. Курс построен так, чтобы превратить хаотичную проверку кода в системный процесс, который повышает стабильность приложений и уверенность разработчика в своих изменениях.

Цель курса. После прохождения курса вы сможете самостоятельно проектировать, реализовывать и поддерживать комплексные наборы тестов для .NET-приложений, а также использовать низкоуровневые инструменты отладки для диагностики критических проблем в продакшене.

Для кого этот курс.

Курс предназначен для .NET-разработчиков с опытом работы от 1 года, которые хотят систематизировать свои знания в области тестирования и отладки. Он будет полезен как для начинающих специалистов, стремящихся внедрить лучшие практики, так и для опытных инженеров, желающих освоить продвинутые техники работы с памятью и производительностью.

Этот курс не для тех, кто только начинает программировать на C#, поскольку он требует понимания основ синтаксиса, работы с классами и интерфейсами, а также базовых принципов объектно-ориентированного проектирования. Если вы никогда не писали тесты или не работали с исключениями, рекомендуется сначала изучить вводные материалы по C#.

Модуль 1. Основы модульного тестирования (Unit Testing)

Введение в модульное тестирование и его ценность. Модульное тестирование — это процесс проверки отдельных изолированных компонентов (юнитов) программного обеспечения, таких как методы класса или функции. Его основная цель — убедиться, что каждый фрагмент кода работает корректно в условиях, заданных разработчиком. В экосистеме .NET модульное тестирование является неотъемлемой частью профессиональной разработки, позволяя быстро выявлять регрессии и документально фиксировать ожидаемое поведение системы. Хорошо написанные тесты служат живой документацией, которая всегда актуальна, в отличие от текстовых спецификаций. Использование фреймворков, таких как xUnit и NUnit, стандартизирует процесс и делает его воспроизводимым на любом проекте, будь то консольное приложение, веб-сервис или библиотека классов.

Фреймворк xUnit.net: современный стандарт. xUnit.net — это бесплатный фреймворк для тестирования с открытым исходным кодом, разработанный создателями NUnit. В отличие от классического атрибута [Test], xUnit использует атрибут [Fact] для обозначения тестовых методов без параметров и [Theory] для параметризованных тестов. Это позволяет писать более чистый и выразительный код. Для управления состоянием тестового класса применяются конструкторы (инициализация) и интерфейс IDisposable (очистка), что отходит от традиционных методов SetUp и TearDown, делая тесты более предсказуемыми. xUnit также славится своей скоростью работы благодаря параллельному выполнению тестов по умолчанию, что критично для больших проектов с сотнями и тысячами тестов.

Фреймворк NUnit: проверенный временем инструмент. NUnit является одним из старейших и наиболее авторитетных фреймворков для тестирования в мире .NET. Его синтаксис хорошо знаком многим разработчикам и основан на классическом подходе с атрибутами [Test], [SetUp], [TearDown] и богатом наборе утверждений (Assert). NUnit предлагает гибкие возможности для параметризации тестов через атрибут [TestCase], что позволяет легко проверять множество сценариев с различными входными данными без дублирования кода. В отличие от xUnit, NUnit предоставляет более детальный контроль над порядком выполнения тестов и поддерживает концепцию [TestFixture] для логической группировки. NUnit остается отличным выбором для унаследованных проектов и команд, предпочитающих явную, многословную конфигурацию.

Паттерн «Arrange-Act-Assert» (AAA). Паттерн AAA — это фундаментальная структура для написания любого модульного теста, обеспечивающая его читаемость и поддерживаемость. Фаза Arrange (Настройка) инициализирует объекты и устанавливает необходимые предварительные условия, например, создает экземпляр тестируемого класса и подготавливает зависимости. Фаза Act (Действие) выполняет само тестируемое действие, например, вызов метода с конкретными аргументами. Фаза Assert (Проверка) верифицирует результат, сравнивая фактическое состояние или возвращаемое значение с ожидаемым. Соблюдение этой структуры превращает тест в понятный сценарий, который легко читать даже спустя месяцы после написания. Нарушение этого порядка, например, смешивание логики инициализации с проверкой, усложняет понимание теста и повышает риск ошибок.

Жизненный цикл тестов и управление состоянием. Понимание жизненного цикла теста критически важно для предотвращения «тестового загрязнения», когда результат одного теста влияет на другой. В xUnit каждый тестовый метод выполняется в отдельном экземпляре класса, а конструктор класса служит для общей инициализации (SetUp). Метод Dispose используется для очистки ресурсов (TearDown). NUnit предоставляет атрибуты [SetUp] и [TearDown], которые выполняются до и после каждого теста, а также [OneTimeSetUp] и [OneTimeTearDown] для действий, выполняемых один раз для всего класса тестов. Это различие важно при работе с дорогостоящими ресурсами, такими как подключения к базам данных — их следует инициализировать один раз, но обязательно сбрасывать состояние между тестами для гарантии изоляции.

Утверждения (Assertions) в xUnit и NUnit. Утверждения являются «глазами» теста, позволяя проверять фактические результаты. xUnit предлагает статический класс Assert с методами, такими как Equal(expected, actual), True(condition), Throws<T>(...) для проверки исключений. NUnit предоставляет более расширенный набор, включая Assert.That(actual, Is.EqualTo(expected)) в стиле fluent-синтаксиса. Оба фреймворка поддерживают проверку коллекций, строк и числовых диапазонов. Ключевое правило — использовать наиболее специфичное утверждение для проверяемого условия. Например, вместо Assert.True(result == 5) лучше написать Assert.Equal(5, result), так как в случае ошибки отладчик покажет ожидаемое и фактическое значения, а не просто сообщение «True was false».

Параметризованные тесты (Theory и TestCase). Параметризованные тесты позволяют выполнять один и тот же тестовый метод с различными наборами входных данных, экономя время и уменьшая количество шаблонного кода. В xUnit для этого используется атрибут [Theory] в сочетании с атрибутом [InlineData], где каждый экземпляр [InlineData] представляет один набор аргументов. Также можно использовать [MemberData] для указания источника данных в виде свойства или метода, что полезно при большом объеме данных или сложных объектах. В NUnit аналогичную функциональность предоставляет атрибут [TestCase], поддерживающий именованные параметры и ожидаемые результаты. Это мощный инструмент для проверки граничных условий и краевых случаев без дублирования логики теста.

Модуль 2. Изоляция кода с библиотекой Moq

Введение в Mock-объекты и необходимость изоляции. В реальных приложениях классы редко существуют изолированно — они взаимодействуют с базами данных, веб-сервисами, файловой системой и другими внешними зависимостями. Модульное тестирование требует, чтобы мы тестировали только логику конкретного юнита, а не поведение его зависимостей. Здесь на помощь приходят моки (mock-объекты) — специальные заглушки, которые имитируют поведение реальных компонентов. Использование моков позволяет контролировать состояние окружения, проверять взаимодействие между объектами и ускорить выполнение тестов, избавив их от медленных I/O операций. Библиотека Moq — это стандартный инструмент для создания таких объектов в .NET, основанный на принципах LINQ и лямбда-выражений.

Основы работы с Moq: создание и настройка моков. Moq позволяет создавать моки для интерфейсов и виртуальных классов. Базовый синтаксис выглядит так: var mock = new Mock<IUserService>();. Для настройки поведения метода используется метод Setup и лямбда-выражение: mock.Setup(x => x.GetUser(It.IsAny<int>())).Returns(new User());. Moq поддерживает «слабые» типизированные проверки через It.IsAny, It.IsInRange и другие, что обеспечивает гибкость при написании тестов. Важно настраивать только те методы, которые реально вызываются в тестируемом коде, чтобы тест был сфокусирован и не содержал лишней логики. Неправильная настройка моков — частая причина ложноположительных или ложноотрицательных результатов.

Проверка вызовов (Verification) в Moq. Помимо подмены поведения, моки позволяют проверить, были ли вызваны определенные методы и с какими аргументами. Это критично для проверки логики взаимодействия, когда метод должен отправлять письмо, логировать ошибку или сохранять изменения в базе данных. В Moq проверка осуществляется методом Verify: mock.Verify(x => x.Save(It.IsAny<User>()), Times.Once());. Метод Times позволяет указать ожидаемое количество вызовов: Once(), AtLeastOnce(), Never() и другие. Чрезмерное использование проверок может сделать тесты хрупкими, поэтому проверять стоит только критически важные взаимодействия, которые непосредственно влияют на результат работы метода.

Продвинутые техники: Callback, Sequence, и Strict Mocks. Moq предоставляет мощные механизмы для имитации сложных сценариев. Callback позволяет выполнить пользовательский код при вызове метода мока, например, для сохранения аргументов в локальной переменной для последующей проверки. SetupSequence используется, когда метод должен возвращать разные результаты при каждом последующем вызове (например, первый вызов возвращает null, второй — объект). Режим MockBehavior.Strict заставляет мок выбрасывать исключение при вызове любого метода, который не был настроен явно. Это полезно для выявления лишних зависимостей в коде, но делает тесты более сложными в поддержке, поэтому рекомендуется использовать его осмотрительно.

Модуль 3. Интеграционное тестирование (Integration Testing)

Интеграционное тестирование: определение и цели. Интеграционное тестирование — это этап проверки программного обеспечения, на котором отдельные модули объединяются и тестируются как группа. В отличие от модульных тестов, интеграционные проверяют взаимодействие между компонентами системы, включая работу с базами данных, файловыми системами, внешними API и очередями сообщений. Основная цель — выявить дефекты на стыках между модулями, такие как несовместимость типов данных, некорректная обработка транзакций или ошибки в сетевых протоколах. В .NET интеграционные тесты часто используют реальные экземпляры DbContext для Entity Framework или тестовые контейнеры для баз данных, чтобы обеспечить максимальную достоверность проверки.

Настройка окружения для интеграционных тестов. Создание надежного окружения — ключевой аспект интеграционного тестирования. Рекомендуется использовать отдельные тестовые базы данных, которые создаются и удаляются для каждого запуска, или использовать транзакции для отката изменений после каждого теста. В современных проектах активно применяется подход с контейнеризацией (например, Testcontainers для .NET), который позволяет поднимать изолированные экземпляры SQL Server, PostgreSQL или Redis прямо во время выполнения тестов. Это гарантирует, что тесты не влияют друг на друга и могут выполняться параллельно. Файлы конфигурации (appsettings.Test.json) используются для переопределения строк подключения и других настроек, чтобы направить запросы к тестовым ресурсам.

Тестирование ASP.NET Core Web API. В экосистеме ASP.NET Core интеграционное тестирование часто выполняется с использованием WebApplicationFactory, которая создает хост приложения в памяти и позволяет отправлять HTTP-запросы через клиент HttpClient. Это позволяет тестировать полный стек — от маршрутизации и привязки моделей до фильтров и middleware. При этом можно подменить сервисы в контейнере внедрения зависимостей, например, заменить реальный сервис отправки писем на мок, сохраняя при этом работу с реальной базой данных. Такой подход дает высокую уверенность в работоспособности API, не требуя развертывания приложения в IIS или Docker.

Работа с внешними API и эмуляция сервисов. При интеграционном тестировании взаимодействия с внешними API (например, платежными шлюзами или соцсетями) прямое обращение к реальным серверам недопустимо. Для этого используются эмуляторы (например, WireMock или собственные реализации на основе HttpMessageHandler). Эмулятор позволяет записывать ожидаемые запросы и ответы, имитируя различные сценарии: успешные ответы, ошибки, тайм-ауты. Это делает интеграционные тесты детерминированными и быстрыми. Важно тестировать как сценарии «счастливого пути», так и обработку ошибок — например, как код ведет себя, если внешний сервис возвращает код 500 или ответ приходит с задержкой.

Баланс между модульными и интеграционными тестами. Оптимальная стратегия тестирования («пирамида тестирования») предполагает, что основу составляют быстрые и дешевые модульные тесты, а интеграционные и сквозные (E2E) тесты используются для проверки критически важных взаимодействий. Модульные тесты должны покрывать сложную бизнес-логику и исключения, в то время как интеграционные — проверять корректность работы с базами данных и внешними системами. Рекомендуемое соотношение — около 70% модульных, 20% интеграционных и 10% E2E. Нарушение этого баланса, например, чрезмерное количество интеграционных тестов, приводит к замедлению сборки проекта и усложнению поддержки.

Модуль 4. Разработка через тестирование (TDD)

Введение в TDD: философия и цикл Red-Green-Refactor. Разработка через тестирование (TDD) — это методология, при которой написание кода начинается с создания автоматического теста, который определяет желаемое улучшение или новую функцию. TDD следует короткому циклу: Red — написать тест, который падает (красная полоса), Green — написать минимальный код, чтобы тест прошел (зеленая полоса), Refactor — рефакторинг написанного кода для улучшения его структуры без изменения поведения. Этот цикл заставляет разработчика четко формулировать требования до написания кода и гарантирует, что весь код покрыт тестами. TDD способствует созданию слабосвязанного, тестируемого и хорошо документированного кода.

Этап Red: написание провального теста. На первом этапе разработчик пишет тест, который проверяет еще не существующую функциональность. Этот тест гарантированно упадет, так как реализация отсутствует. Важно, чтобы тест был простым и проверял ровно одно поведение. На этом этапе запрещено писать какой-либо производственный код, кроме того, который требуется для компиляции теста (например, объявление класса или интерфейса). Падение теста подтверждает, что тест действительно работает и способен выявить ошибку. Если тест проходит до написания кода — это сигнал о том, что тест написан некорректно.

Этап Green: минимальная реализация. Цель этого этапа — сделать тест «зеленым» как можно быстрее. Разработчик пишет ровно столько кода, сколько необходимо для прохождения теста. Допускается использование «грязных» решений, временных констант и жестко закодированных данных, если это помогает пройти тест. Задача — не создать идеальное решение, а заставить тест работать. Это ключевое отличие TDD от традиционного подхода: мы пишем код для теста, а не тест для кода. Это смещает фокус с абстрактного проектирования на конкретные, проверяемые требования.

Этап Refactor: улучшение структуры кода. Когда тест проходит, наступает время рефакторинга. Разработчик может улучшить внутреннюю структуру написанного кода — удалить дублирование, переименовать переменные, упростить сложные условия, выделить методы. Критическое условие: после рефакторинга все тесты должны оставаться зелеными. Это возможно только при хорошем покрытии кода тестами. Рефакторинг — это сердце TDD, так как именно на этом этапе рождается качественная архитектура. Без рефакторинга код становится запутанным и сложным для поддержки, сводя на нет преимущества TDD.

Преимущества и вызовы TDD в реальных проектах. TDD приносит проекту множество преимуществ: снижение количества багов, улучшение дизайна API (так как он тестируется первым), и создание живой документации. Однако, внедрение TDD требует дисциплины и пересмотра привычного процесса разработки. Первое время скорость разработки может упасть, но это компенсируется значительным сокращением времени на отладку и регрессионное тестирование. TDD особенно эффективен в задачах со сложной бизнес-логикой, но может быть избыточен для UI-компонентов или простых CRUD-операций. Рекомендуется применять TDD выборочно, для наиболее критичных и сложных частей системы.

Модуль 5. Профилирование и оптимизация производительности

Цели и методы профилирования .NET приложений. Профилирование — это процесс динамического анализа программы для измерения использования ресурсов: времени выполнения, загрузки процессора, объема выделяемой памяти и количества сборок мусора. В .NET профилирование необходимо для выявления узких мест («бутылочных горлышек») производительности до того, как они повлияют на конечного пользователя. Основные методы включают сэмплирование (периодический сбор данных о стеке вызовов) и инструментирование (внедрение кода для замера времени выполнения каждого метода). Профилирование помогает ответить на вопросы: почему приложение тормозит, почему оно потребляет много памяти, и какой метод является самым медленным.

Инструменты профилирования: от Visual Studio до JetBrains dotMemory. Экосистема .NET предлагает широкий спектр инструментов для профилирования. Встроенный профилировщик Visual Studio (Diagnostic Tools) отлично подходит для быстрого анализа CPU и памяти в процессе разработки. Для углубленного анализа памяти рекомендуется использовать JetBrains dotMemory, который позволяет делать снимки памяти (snapshots) и сравнивать их, выявляя утечки и объекты, переживающие сборки мусора. Для анализа производительности CPU применяется JetBrains dotTrace и PerfView (бесплатный инструмент от Microsoft). PerfView особенно полезен для анализа больших продакшен-систем и сбора ETW-событий (Event Tracing for Windows).

Анализ сборщика мусора (GC) и управление памятью. Сборщик мусора в .NET автоматически управляет памятью, но неправильное использование объектов может приводить к частым остановкам приложения (GC pauses). В ходе профилирования важно обращать внимание на количество сборок мусора поколения 0, 1 и 2, а также на размер кучи. Большое количество объектов, переживающих поколение 0, говорит о необходимости оптимизации времени жизни объектов. Распространенные анти-паттерны: создание большого количества временных объектов в циклах, неиспользование пулов объектов (Object Pooling) и захват больших объектов (Large Object Heap). Анализ GC помогает оптимизировать код, снижая нагрузку на сборщик мусора и повышая пропускную способность приложения.

Профилирование многопоточных и асинхронных приложений. Отладка и профилирование асинхронного кода представляют собой особую сложность из-за переключения контекстов и потенциальных проблем с синхронизацией. Инструменты профилирования должны поддерживать визуализацию потоков и задач (Tasks). Важно измерять не только время выполнения самого кода, но и время ожидания (например, при вызовах await для I/O операций). Проблемы, такие как взаимоблокировки (deadlocks) или голодание пула потоков, часто проявляются именно в асинхронной среде. Использование метода Task.Run без необходимости или неуправляемый доступ к общим ресурсам могут привести к падению производительности.

BenchmarkDotNet: научный подход к бенчмаркам. BenchmarkDotNet — это мощная библиотека для написания эталонных тестов (benchmarks) в .NET. Она позволяет точно измерять производительность методов, учитывая такие факторы, как JIT-компиляция и оптимизации среды выполнения. Бенчмарки оформляются как обычные классы с атрибутом [MemoryDiagnoser] для отслеживания выделяемой памяти. Библиотека автоматически запускает тесты в нескольких итерациях, отбрасывает выбросы и выдает статистически значимые результаты. BenchmarkDotNet — это обязательный инструмент для сравнения различных реализаций одного алгоритма или выбора оптимальной стратегии работы с коллекциями. Результаты бенчмарков должны быть частью CI/CD процесса для контроля регрессий.

Модуль 6. Отладка (Debugging) и WinDbg

Основы отладки в Visual Studio. Отладка — это процесс выявления и устранения ошибок (багов). Интегрированная среда разработки Visual Studio предоставляет мощный отладчик, который позволяет разработчикам устанавливать точки останова (breakpoints), пошагово выполнять код, просматривать значения переменных и стек вызовов. Современная отладка выходит за рамки простого Console.WriteLine и включает такие фичи, как «Edit and Continue» (изменение кода во время отладки), условные точки останова и точки трассировки. Эффективное использование отладчика значительно ускоряет решение проблем по сравнению с методом «копирования ошибки» и позволяет заглянуть внутрь выполнения приложения в реальном времени.

Продвинутая отладка: дампы памяти и постмортем-анализ. В продакшен-среде часто невозможно остановить приложение и подключить отладчик. Здесь на помощь приходят дампы памяти (crash dumps) — файлы, содержащие состояние процесса в момент аварийного завершения или по запросу. Анализ дампов позволяет выяснить причину ошибки постфактум (post-mortem debugging). Для работы с дампами используются специализированные инструменты: WinDbg и SOS.dll. Дамп содержит информацию о загруженных модулях, управляемых объектах, потоках и исключениях, что позволяет воспроизвести картину состояния системы на момент сбоя, даже если исходный код недоступен.

WinDbg: инструмент низкоуровневой отладки. WinDbg — это мощный отладчик от Microsoft, который используется для низкоуровневой отладки ядра и пользовательского режима. В контексте .NET он незаменим для анализа сложных проблем, таких как утечки памяти, высокие нагрузки на процессор, зависания (hang) и взаимоблокировки, которые невозможно выявить стандартными средствами. WinDbg работает с символьными файлами (PDB) и позволяет исследовать внутреннюю структуру процесса. Его интерфейс преимущественно командный, что дает разработчику полный контроль над процессом отладки.

SOS.dll — расширение WinDbg для .NET. SOS (Son of Strike) — это расширение для WinDbg, которое добавляет команды для анализа управляемого кода. Загружается оно командой .loadby sos clr или .load sos (в зависимости от версии .NET). Основные команды SOS: !threads (потоки), !clrstack (управляемый стек вызовов), !dumpheap (содержимое кучи), !gcroot (корни объекта) и !dumpobj (содержимое объекта). Команда !analyze -v часто используется для автоматического анализа причин исключений. Без знания SOS анализ дампов .NET приложений практически невозможен.

Диагностика OutOfMemoryException и утечек памяти. Утечка памяти в .NET обычно возникает не из-за неуправляемых ресурсов, а из-за того, что объекты неожиданно продолжают удерживаться в памяти, несмотря на то, что они больше не нужны. Это часто происходит из-за подписки на события (Event Handlers), статических ссылок, или объектов, помещенных в кэш без ограничения по размеру. Для диагностики утечек используется анализ дампов с помощью SOS: команда !dumpheap -stat показывает, какие типы занимают больше всего памяти, а !gcroot показывает, кто держит ссылку на объект. Поиск и устранение таких утечек критически важны для стабильности долго работающих служб.

Анализ High CPU и проблем производительности через WinDbg. Проблемы высокого потребления CPU часто вызваны бесконечными циклами, интенсивными вычислениями или частыми сборками мусора. При анализе таких проблем с помощью WinDbg, необходимо получить дамп процесса в момент пиковой нагрузки. С помощью команды !threads идентифицируются активные потоки, а затем с помощью !clrstack анализируются их стеки вызовов, чтобы определить, какой код выполняется в данный момент. Часто проблема заключается в интенсивной работе со строками или неправильной настройке пула потоков. Анализ стеков позволяет точно локализовать проблемный метод и оптимизировать его.

Модуль 7. Лучшие практики и автоматизация

Качество тестов: как избежать «хрупких» тестов. «Хрупкие» (brittle) тесты — это тесты, которые падают без изменения производственного кода, например, из-за изменения порядка элементов в коллекции или времени выполнения. Для избегания этого необходимо следовать принципам: тестировать поведение, а не реализацию; избегать проверки строковых представлений дат и чисел; использовать специальные утверждения для коллекций (Assert.Contains вместо проверки всего массива). Важно избегать логики (условий и циклов) внутри самого теста, так как это делает его сложным для понимания. Хороший тест должен падать только тогда, когда в системе действительно есть ошибка.

Именование тестов: выражение намерений. Имя тестового метода — это его документация. В .NET сообществе распространен паттерн MethodName_StateUnderTest_ExpectedBehavior. Например, AddUser_WhenUserIsValid_ShouldReturnSuccess. Такое название читается как предложение и сразу дает понять, что делает тест и каков ожидаемый результат. Избегайте общих названий вроде Test1 или TestAddUser. Хорошее название описывает сценарий и помогает другому разработчику понять бизнес-требования без необходимости читать весь код. Это также упрощает чтение отчета о прогоне тестов.

Автоматизация запуска тестов в CI/CD. Модульные и интеграционные тесты должны выполняться автоматически при каждом изменении кода в репозитории. Современные системы CI/CD, такие как Azure Pipelines, GitHub Actions и TeamCity, позволяют настроить запуск тестов с помощью команды dotnet test. Этот процесс включает восстановление зависимостей, сборку и выполнение тестов с генерацией отчетов о покрытии. Автоматизация гарантирует, что регрессии будут обнаружены на ранних стадиях, предотвращая попадание ошибок в продакшен. Важно интегрировать запуск тестов в процесс Pull Request, чтобы блокировать слияние кода, нарушающего работу существующих функций.

Анализ покрытия кода тестами (Code Coverage). Покрытие кода измеряет долю кода, которая выполняется во время прогона тестов. Инструменты, такие как Coverlet и Fine Code Coverage, интегрируются с .NET и показывают, какие строки кода покрыты тестами. Высокий процент покрытия не гарантирует качество, но низкий сигнализирует о рисках. Цель — не достичь 100% любой ценой, а покрыть критическую логику и краевые случаи. Анализ покрытия помогает выявить «мертвый» код, который никогда не выполняется, и сконцентрировать усилия по тестированию на наиболее сложных и важных участках системы.

Документирование тестов и работа с багами. Тесты — это лучшая документация, но важно, чтобы они оставались релевантными. При нахождении бага сначала пишется тест, воспроизводящий этот баг (и он падает), затем баг фиксится, и тест становится зеленым. Это гарантирует, что ошибка больше не вернется (regression test). Комментарии в коде тестов должны объяснять, почему проверяется конкретное условие, особенно если логика связана со специфическим бизнес-требованием. Ведение бэклога тестов (что нужно покрыть в первую очередь) помогает управлять техническим долгом.

Модуль 8. Применение в реальных проектах