Все ругают самописные тестовые фреймворки. А мы своим довольны

Ссылка на Хабр

Коллеги с соседнего проекта написали статью про один из наших тестовых фреймворков. Очень круто все описали!

О том, как развивались автотесты продукта Фактор, где сейчас этих автотестов тысячи. Да, это бывает по тысяче строк в одном файле, казалось бы «фи, скукота, я то думал, тысяча строк юнит-тестов». Но нет, мы пришли к DDT и тому, чтобы один раз написать фреймворк, а потом получать «один тест = одна строка во входном и выходном файле».

Ребята рассказали про заглушки внутри тестов, учет статуса задачи в JIRA и про другие примочки. Это круто, я когда-то хотела про каждую отдельный постик написать. А, может, еще и напишу, но уже сейчас можно посмотреть «а как у них это работает».

Может, даже идеи для ваших автотестов появятся. Потому что с JIRA мы круто сделали, я считаю. Прикиньте, тест вроде заскипан (падение игнорируется при прогоне), но, если вдруг заработал сам по себе, система сигнализирует об этом. А то бывает же, что делаешь другую задачу и тут, опа-опа, что-то еще починил ¯\_(ツ)_/¯

Так что приятного чтения!

См также:
Автотесты на уровне API для Java-приложений — про тесты на моем проекте
Больно пилить автотесты? Проси улучшать! — и как мы их улучшали

Expected «null», but was «null» в автотестах

Как мне нравится, когда автотесты падают на null и пробелах))) Первый раз при отладке такого теста ты вообще не понимаешь, что не так. Потом запоминаешь...

Собрала несколько любимых примеров из жизни, зацените:


Null

Допустим, должна быть пустая строка, а ты туда текстом null вписал. Тест падает:

expected «null», but was «null»

Угадай, что не так ¯\_(ツ)_/¯

Fail test не должен прерывать сборку

Не отменяй меня!!

Этот пост прям накипел ツ

Сейчас читаю книгу «Непрерывное развертывание ПО» и там прочитала такой лайфхак:

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

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

Больно пилить автотесты? Проси улучшать!

Есть у нас в базе таблица, где хранится плоская запись. Точнее, хранилась, теперь там BLOB. Но не суть. В плоской записи 600 полей, которые называются field_1, field_2... field_600.

В коде зашит меппинг этих филдов на нормальные названия:

<entry key="cat" value="6"/>
<entry key="dog" value="13"/>
...
<entry key="human" value="15"/>

Файлик с меппингом назовем... Ну, допустим, р2о (plain to object). Он с хитринкой — так как в java отсчет начинается с нуля, а не с единицы, то к value надо было добавить 1, чтобы получить field в базе. Вот, например, key="cat" → в базе это был field_7.

Сами по себе поля field_* проблем не приносили, потому что обычно база заполнялась из файликов, а дальше уже темная магия все разруливала и сразу красота! А вот в автотестах всегда черт ногу сломит. Открываешь тест, тебе надо поправить фамилию. А у тебя на входе эти 600 полей. И в каждой сборке свой меппинг. Где-то фамилия — это номер 2, где-то номер 4, где-то 6, и так далее.

И вот ты такой открываешь тест, который надо поправить. Открываешь р2о. Находишь там нужное тебе поле. Сидишь, тупишь, вспоминая, надо от value отнять единичку или прибавить... Правишь тест. Профит! Но затупы на «отнять или прибавить» особенно раздражали.

А уж если кто-то внес изменения в р2о! Изменил одно поле? Все, гудбай все тесты → рассыпались как карточный домик, надо ходить и уныло актуализировать. Так как актуализацией занималась я, то и страдала тоже я 

Страдала я громко, плакалась на митингах и в чатике:
— Опять тесты развалились из-за р2о. Давайте сделаем так, чтобы они не падали??
— Оля, отстань! Зачем тратить на это ресурсы? Не так уж часто р2о меняется. Один раз в год подняла тесты, это проще, чем тратить пару дней разработчика.

В общем, в случае пожара — горите.

Тебе тяжело? Ты и страдай