Наладили контакт с коллегами, попили пиво в ирландском пабе, сходили на джазовый концерт, вдохновились творчеством Рембрандта, но коллеги так и не научились писать автотесты? Время перейти от контакта к коду.

Перед тем как писать код нужно организовать процесс работы и установить контакт с коллегами. Подробнее об этом я писал в статье «Как научить писать автотесты с нуля. Взгляд, искра, буря, pull request.». Теперь пришло время поговорить непосредственно о коде. Давайте рассмотрим пример selenium проекта. Данный проект придуман специально для этой статьи, поэтому фокус тут на техниках обучения, а не на самом коде и структуре проекта. Итак, начнем.

  1. Объяснение структуры проекта на пальцах

    В проекте много разных папок и файлов. Все  они там не просто так, но чтобы начать писать простые тесты многие из папок и файлов не нужны. Гораздо лучше выделить основное сказав, что пока тебе нужна эта папка, в ней лежит то-то и то-то и эта папка. Остальное пока не трогай и не обращай внимания. Чем меньше информации на старте, тем меньше каши будет в голове.

  2. Минимальный набор для запуска теста

    Чтобы тест заработал хоть как-то, в нем должны быть обязательные части. Например, название функции, которое начинается с «test_», некоторые параметры на входе и т.д. Эти все обязательные части надо показать. Можно пока не вникать что это такое и для чего нужно. Просто сказать: чтобы начать писать тест нужно скопировать эти строки в новый файл и отредактировать название, а уже позже разберемся что это такое и как работает. Такой минимальный набор. Т.е. что точно должно быть в файле с тестом, иначе не заработает.

  3. Написать тест линейно и еще sleep в конце поставить

    Не нужно рассказывать, что в таком-то файле должны лежать функции для действий на странице, в такой-то папке нужно писать локаторы и так далее. Очень сложно разобраться на старте что куда нужно положить. Поэтому начать лучше с линейного написания теста. Что это значит: весь код находится в одном файле, в одной функции. Код не разбит по функциям/классам/папкам. Все в одном файле линейно. Без ООП, обвязок, украшательств и прочего. Голый файл, голый селениум, одна функция, везде хардкод, данные и логика перемешаны. В конце еще люблю ставить sleep(), чтобы браузер сразу не закрылся и можно было визуально посмотреть, что все сработало как надо. Это проще и доверительнее для новичка (да и не только), чем смотреть на зеленую галочку об успешном прохождении теста

  4. Выделить части кода и показать что и где должно лежать

    Написали тест в одном файле, работает на отлично. Теперь пришло время сказать что и где на самом деле должно лежать. Например, эти две строки должны находиться в папке framework и они у нас уже есть, эти данные должны лежать в файле с остальными данными, этот блок нужно разбить на отдельные функции, sleep нам не нужен, sleep в итоговом коде всегда плохо. 

  5. Объяснить с чего надо начать и дать четкие инструкции

    Разобрались с простым тестом, пора двигаться дальше. И вот вы налили кофе, сели, расслабились, представили как будет выглядеть следующий тест, открыли любимую IDE и что дальше? На этот вопрос «что дальше» пришлось отвечать не один десяток раз. Очень сложно понять какие действия приведут к конечному результату. И самый главный вопрос: с чего начать? Т.е. самое первое действие, которое вы делаете, чтобы начать писать тест. Тут методики могут быть разными, но я сначала смотрю что уже написано для теста вот в этих папках, а что надо дописать. Иными словами начинаю смотреть какие части моего теста уже написаны прежде, чем я начну делать рыбу.

  6. Объяснить что такое фикстуры

    Отдельно потратьте время, чтобы объяснить особенности вашего фреймворка. К примеру, если вы используете pytest, объясните что такое фикстуры, где лежат, как использовать. Это сильно облегчает написание теста и переиспользование того кода, что уже есть.

  7. Тест-конструктор: собери тест из готовых функций

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

  8. Каркас теста: заполни пустые функции

    Похожая техника, что и в предыдущем пункте, только на этот раз мы добавляем все функции, которые должны быть и предлагается заполнить кодом и логикой функции самому. В тесте можно написать шаги в комментарии, либо вызвать эти функции в тесте, чтобы было видно какие конкретно функции нужно заполнить.

  9. Команда А: дать один тест нескольким людям

    Если вы обучаете несколько человек, то еще один интересный опыт: дать написание одного теста нескольким людям. Они обменяются идеями, разделят работу между собой, поделятся знаниями и вообще помогут друг другу.

  10. Дать выбрать задачу самому

    Выберите несколько тест-кейсов и дайте выбрать один. В этом случае ученик выберет наиболее привлекательный тест-кейс, который захочет сам автоматизировать. Так он получит больше удовольствия и не будет отвлекаться на что-то еще. Иногда стоит подсказать с какими проблемами столкнется, если возьмет тот или иной тест-кейс.

  11. Личное ревью всех пулл реквестов

    Лично проверяйте пулл реквесты. Желательно стянуть к себе ветку и внимательнее посмотреть на код. Так вы сможете лучше сказать что не так в коде, где ошибка в логике. Чтобы потом не было сюрпризов, когда что-то не доглядели.

  12. Бить по рукам за критичные ошибки более опытных коллег

    Есть ситуации, когда вы можете закрыть глаза на недочеты, а когда ошибка очень критична. Не нужно оставлять такой код с комментарием «потом отрефакторим». Во-первых, нет, не отрефакторите, во-вторых, новички видят код и принимают его за эталон и учатся на таких примерах. Не удивляйтесь потом, когда подобные недосмотры будут появляться в коде новичков. Код не должен быть вылизан на 100%, но и критичных замечаний быть не должно тоже. О том что такое хороший пулл-реквест и как его проводить читайте в статье «Что такое хороший Pull Request и какие скилы нужны, чтобы его отревьюить.»

  13. Делать акцент на частые ошибки новичков

    Делайте акценты на частые ошибки новичков. Ругать никого не нужно, просто объясняйте почему так делать не стоит. Не пишите ошибку в общий чат с указанием человека. Разъясняйте все лично. Только если ошибка у всех часто повторяется можно объяснить в общем чате, но без конкретных имен.

Вот, пожалуй, все основные техники, которыми я пользуюсь. Если у вас есть что предложить или дополнить, напишите в комментариях.

Please follow and like us:
error

Оставить комментарий

avatar