Подход к тестированию

Основные принципы автоматического тестирования 

  1. Тесты, использующие БД, должны исполняться на тестовой БД
  2. Каждый тест (с доступом к реальной БД) должен очищать за собой те сущности, которые он сгенерировал (такие тесты должны наследоваться от TestBase и реализовывать метод TestCleanup())
    1. Так исключается ситуация, когда тесты могут очистить за собой и удалить реальные данные из DB
    2. В реальной DB не будут видеть тестовые данные (в случае, если какой то тест не очистил данные после себя)
  3. Тесты должны запускаться на любой машине, т.е. не должны зависеть от контекста конкретного ПК (БД, записи в БД, файла и др.)
  4. Тесты должны автоматически прогоняться на специальной отдельной машине (GitLab, настроенный на тесты, выполняющий их после каждого коммита в каждой ветке)
  5. Ветка в системе контроля версий считается законченной, если все тесты в ней выполняются без ошибок (проверять перед слиянием с develop)
  6. Тесты должны быть оформлены с использованием паттерна AAA(Arrange, Act, Assert). Например:12345678// Arrangevar employeeRequest = CreateEmployeeRequest(); // Actvar result = await _module.Create(employeeRequest); // AssertAssert.Equal(result.Code, ResultCode.Ok);
  7. На тесте необходимо навешивать атрибут с типом теста. В дальнейшем, можно фильтровать по категориям и запускать определённые тесты (например, Unit тесты, не требующие БД) (* продумать)
    1. [Trait(«Category»,»Unit»)]
    2. [Trait(«Category»,»Integration»)]
    3. [Trait(«Category»,»Functional»)]
    4. [Trait(«Category»,»WebAPI»)]
    5. [Trait(«Category»,»UI»)]
  8. Каждый тест должен быть атомарным, т.е. должен проверять только одну вещь (в идеале, должен быть один Assert)
  9. Тест должен cоблюдать единую конвенцию именования [тестируемая единица]_[сценарий]_[прогнозируемое поведение]ПримерыGetByPhone_ValidRequest_ReturnSuccess
  10. GetSame_ByDefault_ReturnsTrueSum_ByDefault_ReturnsZero
    Add_WhenCalled_ChangesSum
    Sum_Always_CallsLogger
    IsValidFileName_BadExtension_ReturnsFalse
    IsValidFileName_ValidExtension_ReturnsTrue
    IsValidFileName_EmptyFileName_Throws
    IsValidFileName_WhenCalled_ChangesWasLastFileName
    IsValidFileName_ExtManagerThrowsException_ReturnsFalse
  11. Тесты должны обладать достаточно хорошей читабельностью. Для того чтобы тесты читались как книга, они должны быть декларативными, с минимальным количеством лишних деталей
    1. Для генерации сложных тестовых объектов использовать Fixture, что бы спрятать детали создания классов.
  12. Тесты, исполняемые только на локальной машине (если в таких есть необходимость) помечать атрибутом [Fact(Skip=»reason»)]
  13. Категории тестов следует разделять по директориям

    MyLibrary.UnitTests
    MyLibrary.IntegrationTests

Тестирование профилей автомаппера

Небольшая ремарка по поводу профилей автомаппера и их тестировании:
Профили размещаются в папке MappingProfiles в проектах подсистем.
Например, Telecom\Reports\MappingProfiles
При добавлении нового профиля, его необходимо добавить в тест.
Профили тестируются в соответствующей подсистеме в классе AutoMapperConfigurationTest
Например, Tests\Telecom.Reports.UnitTests\AutoMapperConfigurationTest.cs
Mapper.Initialize(cfg =>
{
     cfg.AddProfile<ReportMappingProfile>();
});

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


Добавить комментарий