Тестирование Trainer Advisor: теория

Введение

Это первый пост об устройстве тестирования Trainer Advisor. В этом посте я расскажу какие принципы и модели лежат в основе тестирования TA, а в последующих постах подробно разберу все ключевые виды тестового кода в проекте.

Но начать надо с того, чтобы решить куда мы хотим прийти - какими должны быть тесты?

Что такое хороший тест?

На мой взгляд, хороший тест, это показательный тест. Если все тесты на фичу прошли, не должно быть такого, что пользователь при первом же взаимодействии с этой фичей находит баги. И наоборот, если был выполнен аккуратный рефакторинг (изменение структуры кода, без изменения его поведения), который не внёс регрессий (и пользователь это подтвердит) - тесты не должны сломаться.

Для того чтобы тесты были показательными, я считаю, что надо [стремится] придерживаться трёх основных правил:

Все эти правила, не являются догмами и в реальной практике их приходится нарушать:

Поэтому у меня есть только одно жёсткое правило, контролируемое автоматически - код методов HTTP эндпоинтов должен быть покрыт на 100% тестами, работающим через HTTP API с приложением без моков.

Так же, так как у меня нет отдельной команды QA, я бы хотел ещё одно жёсткое автоматически контролируемое правило - все ключевые элементы вёрстки (самое главные - поля ввода, формы и ссылки, а так же - динамические строки, включая сообщения об ошибках) должны быть покрыты тестами на 100% . Но я не вижу способа как это можно сделать, поэтому к следованию этого правила я просто стремлюсь.

Практика Trainer Advisor, Проекта Э и других проектов сделанных по Эргономичному подходу такова, что одни только такие тесты (покрывающие 100% эндпоинтов и ключевых элементов вёрстки) обеспечивают примерно 90% покрытия кода, и необходимость в тестах на более низких уровнях абстракции возникает довольно редко.

Это хорошо видно по цифрам распределения видов тестов в Trainer Advisor:

При том 149 не-e2e тестов на моей машине (i7-8700, 32GB Ram, SSD) проходят за 9.5 секунд, в среднем - ~64мс на тест, если вас беспокоит время выполнения внешних тестов. Для сравнения, два теста с моками занимают порядка 600-700 на первый и 150-200 на второй тест.

Виды тестового кода и их общая структура

Для того, чтобы придерживаться трёх основных правил, мне приходится писать достаточно много фикстурного кода - кода, который упрощает написание тест кейсов, удовлетворяющих этим правилам.

В цифрах это:

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

Я выделяю одиннадцать (🤦‍♂️) видов тестового кода:

Все эти виды кода и зависимости между ними можно визуализировать так:

На этой картинке в первую очередь надо обратить внимание на то, что кейсы зависят от продового кода только косвенно - они могут объявлять переменные классов продового кода, но всё взаимодействие с ними - создание и обращение к полям и методам идёт через фикстурный код. Это позволяет ограничить "площадь поражения" рефакторинга продового кода несколькими методами фикстурного кода, а не десятками и потенциально сотнями методами кейсов.

Структура директорий тестов

Сейчас структура директорий строго не регламентирована, но общий план такой:

В Trainer Advisor это выглядит так:

Тестовый код	Продовый код

Именование тестов

Общая структура тест кейса - Given/When/Then

Методы тест кейсов я структурирую "по классике" - через Given (Дано, при условии что), When (Когда), Then (Тогда) (aka Arrange, Act, Assert).

@Test
fun `Search result should not contain duplicates when a time zone matches both id and title`() {
    // Given
    val timeZoneId = "Asia/Novosibirsk"
    val timeZoneTitle = "Нововсибирск"

    // When
    val searchResult = russianTimeZones.search(timeZoneId, timeZoneTitle)

    // Then
    searchResult.shouldBeUnique()
}

@Test
fun `Creation of appointment, that intersects with an appointment in another time zone should fail`() {
    // Given
    val existingAppointmentTimeZone = asiaNovosibirsk
    val newAppointmentTimeZone = europeMoscow
    val existingAppointmentLocalDateTime = aDateTime

    backgrounds.appointments.create(
        dateTime = existingAppointmentLocalDateTime,
        timeZone = existingAppointmentTimeZone
    )

    val createNewAppointmentRequest = randomEditAppointmentRequest(
        client = ClientsObjectMother.fakeClientRef,
        // Этой строчкой я хотел отразить, что астрономическое время нового приёма
        // совпадает со временем старого приёма, но сейчас кажется, что лучше это
        // было сделать через вывод двух LocalDateTime из одного Instant.
        dateTime = aDate.atTime(existingAppointmentLocalDateTime.get(ChronoField.HOUR_OF_DAY) - timeZonesDiff, 0),
        timeZone = newAppointmentTimeZone
    )

    // When
    val result = controller.createAppointment(
        createNewAppointmentRequest,
        theTherapistUserDetails
    )

    // Then
    result.shouldBeIntersectionError()
    backgrounds.appointments.getDaySchedule(aDate) shouldHaveSize 1
}

Не по классике у меня то, что я допускаю секции "And when" и "And then". Хотя и стараюсь их избегать.

@Test
fun `After submit of registration form therapist should be created and creds should be sent to admin and success response should be returned`() {
    // Given
    val registerTherapistRequest = registerTherapistRequest(
        "Сергей",
        "Сергеев",
        "new-therapist@qyoga.pro"
    )

    // When
    val document = PublicClient.authApi.registerTherapist(registerTherapistRequest)

    // Then
    document shouldHaveComponent RegistrationSuccessFragment

    // And then
    val receivedMessages = greenMail.getReceivedMessagesForDomain(adminEmail)
    receivedMessages shouldHaveSize 1
    // Здесь я нарушаю правило "код должен делать одну вещь"
    // shouldMatch - и верифицирует сообщение и извлекает из него данные.
    // Если бы я вылизывал этот код, чтобы сделать из него эталон - я бы, скорее всего
    // вытащил получение емейла и пароля в отдельный метод.
    val (receivedTherapistEmail, password) = receivedMessages[0] shouldMatch registerTherapistRequest

    // And when
    val therapist = TherapistClient.login(receivedTherapistEmail, password)
    val getClientsResponse = therapist.clients.getClientsListPage()

    // Then
    getClientsResponse shouldBe ClientsListPage
}

Разработка, направляемая тестами

Ортогональным всем описанным выше принципам и практикам является вопрос "Когда писать тесты?" - до или после продового кода? Я долгое время утверждал, что классическая школа ТДД является одним из столпов Эргономичного подхода. Однако при написании этого поста, я понял что в целом я хоть и сторонник "tests-first" разработки, назвать мой подход Tests-Driven Development (или даже Design) - нельзя.

У меня при словах "test-driven development" в памяти всплывают видео, на которых Мартин как сумасшедший мечется налево и направо и долбит в воздухе по воображаемой клавиатуре, изображая ежесекундное переключение между тестовым и продовым кодом; или как Куксенко или Кекс под лозунгом "самый простой код, который сделает тест зелёными" пишет какую-то полную дичь, которую очевидно придётся переписать на следующей же итерации.

Моя работа проходит не так. Новые фичи я действительно обычно начинаю писать с внешнего теста (работающего через HTTP), но у меня намного более длинный цикл (надеюсь, я в этом году всё-таки созрею до того, чтобы записать видео моего процесса разработки), в отличие от Мартина и я не пишу код на выброс, в отличие от Куксенко.

Фиксы я тоже начинаю с теста, но тут уже наоборот в первую очередь пытаюсь сделать более простой внутренний тест (работающий через прямой вызов метода контроллера), переходя к внешнему, только если ошибка видима только на уровне вёрстки.

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

Заключение

В этом посте я рассмотрел основополагающие принципы и модели, которых придерживаюсь при разработке тестов Trainer Advisor. В следующем посте я подробно расскажу всю мякотку самой "волосатой" части тестового кода - сетапа фикстуры - как я управляюсь с БД и создаю тестовые объекты.