Как реализовывалось тестирование на последнем месте работы?

Да ты послушай, на что мы с командой подписались на том проекте! Тестирование там было выстроено так, что любая ошибка, как говно в вентилятор, сразу на всех летела. В общем, многоуровневая стратегия, впаянная прямо в CI/CD-пайплайн, чтобы ни одна кривая сборка не просочилась.

1. Модульные тесты (Unit Tests):

• Инструменты: xUnit (ну его нахуй, он быстрее) или NUnit, а для подмены зависимостей — Moq, чтобы не тянуть всякую хуйню.
• Цель: Проверить, чтобы каждый мелкий класс или метод сам по себе не гнал пургу. Изоляция полная, блядь.

• Вот, смотри, как это выглядело:

  [Fact]
  public void CalculateDiscount_ForPremiumCustomer_Returns20Percent()
  {
      // Arrange (Готовим)
      var customer = new Customer { IsPremium = true };
      var calculator = new DiscountCalculator();
  
      // Act (Делаем)
      var result = calculator.CalculateDiscount(customer, 1000);
  
      // Assert (Проверяем)
      Assert.Equal(200, result); // 20% от 1000, епта!
  }

• Покрытие: Гнали как угорелые, чтобы было за 80% (меряли через Coverlet). Меньше — стыдно было в глаза коллегам смотреть.

2. Интеграционные тесты (Integration Tests):

• Инструменты: xUnit + WebApplicationFactory<T> для API и Testcontainers, чтобы поднять настоящую базу в Docker. Это ж просто ёперный театр!
• Цель: Убедиться, что все эти штуки — контроллеры, сервисы, база — между собой не переругались и работают.
• Важный момент: Базу для тестов каждый раз сносили и создавали заново, чтобы тесты друг другу не наследили, как пьяные в подъезде.

3. Сквозные тесты (End-to-End / E2E Tests):

• Инструменты: Playwright для веба и Postman/Newman для API.
• Цель: Сымитировать самого долбоёба-пользователя, который будет тыкать всё подряд на стенде (Staging).
• Запуск: Их гоняли реже — ночью или перед выкаткой. Потому что они, блядь, медленные и хрупкие, как яйца.

4. Интеграция в CI/CD:

• GitHub Actions / Azure DevOps: Как только кто-то создавал пулл-реквест — сразу стартовали модульные и быстрые интеграционные тесты. Автоматом, ёба!
• Порог: Если тесты падали или покрытие проседало — вся сборка летела в пизду, и мерж был невозможен. Жёстко, но справедливо.
• Артефакты: Все результаты и отчёты о покрытии складывались в артефакты пайплайна. Потом можно было тыкать пальцем и разбираться.

Ну и по мелочи:

• Пирамида тестов: Куча модульных, поменьше интеграционных, и совсем чуть-чуть E2E. Как в жизни — фундамент должен быть большим.
• Читаемость: Использовали Given-When-Then, чтобы даже новичок мог въехать, что тут тестируется.
• Моки и стабы: Чётко разделяли. Moq — когда надо проверить, что один компонент позвал другой. А простые стабы — когда надо просто подсунуть нужные данные, и похуй.