Как начать писать тесты?

Собственно, возник такой вопрос.

Подход «взять и начать» — не работает. Не понятно, что тестировать, что нет, какие случаи всегда полезно помнить и т.п.

Но понимаю, что умение писать тесты очень пригодится мне в будущем (в данный момент я заканчиваю 11-й класс и планирую поступать в ВУЗ по IT-шной специальности).


Заранее спасибо за любой совет!

P.S. Основное время программирую на Perl'e и Python'e. Если есть советы конкретно по этим языкам — буду вдвойне благодарен.
  • Вопрос задан
  • 7305 просмотров
Решения вопроса 1
klen
@klen
Когда не знаешь, в какой момент писать тесты, заведи простую привычку: нашел баг, прежде чем закрыть, покрой тестом который его ловит. При таком подходе с динамическим языком и не заметишь как весь проект тестами обрастет. А потом когда поймешь профиты вполне может сформироваться привычка и склонность к ТДД.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
Stdit
@Stdit
Тесты нужны в первую очередь в тех местах, которые могут сломаться. Это, как правило, сложнозависимые места. Начинать писать тесты на самом верхнем уровне, например на api модели и http раутинги (если это веб), постепенно спускаясь вниз до разумных пределов. А вообще, в истинном дзен-TDD начала пишутся тесты, а потом уже функциональность под них.
Ответ написан
Комментировать
@egorinsk
Тесты стоит писать для компонент, которые с большой вероятностью легко сломать (и которые вызовут у вас трачу времени на поиск проблемы). Если у вас есть код, выводящий из БД табличку или добавляющий пользователя, или типичный контроллер, или типичная модель, нет смысла его тестировать.

А вот, если у вас к примеру есть класс HumanDateParser, который разпознает даты в тексте и возвращает их в виде timestamp, для него стоит сделать тест. Простейший тест будет словарь, вида строка — ожидаемый ответ, например (извините, Питон не знаю, пишу на яваскрипте):

var answers = {
«14 мая 2002»: '2002-14-05',
«4 апреля»: '$currentYear-04-04',
«114 марта»: false,
«туруру»: false
};

После чего простейший цикл перебирает значения из словаря, скармливает их HumanDateParser и сравнивает ответы, если что-то не так, трубит об ошибке. Если потом вы найдете баг в этом модуле, вы добавите в answers строки, которые вызывали баг.

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

А делать тесты ради тестов и 100% покрытия, по моему, глупо. Не забывайте, к примеру, что в случае каких-то изменений в покрытом коде вам, скорее всего, придется еще и переделывать тесты.
Ответ написан
colonel
@colonel
Разработчик PHP, Laravel
Прочитай книги о TDD.
Мне, в свое время, очень помогла эта
Ответ написан
Комментировать
Мне помог такой подход на существующем коде:
— функциональные/приемочные тесты на новые или изменяемые фичи (по сути описание ТЗ на неком DSL)
— модульные/интеграционные при рефакторинге
— тесты на баги

И не надо в большинстве случаев, имхо, тестировать внутреннее состояние хоть системы в целом, хоть отдельных её объектов или переменных. Тестировать нужно её поведение. Соответствие результата ожидаемому. При этом нужно ориентироваться на семантику, а не на знание внутренностей, не нарушать инкапсуляцию. При таком подходе не нужно будет писать, например, тесты на геттеры и сеттеры отдельно, достаточно написать один тест, что значение, возвращаемое геттером равно установленному раннее сеттером. Или, переходя на систему в целом, не нужно тестировать что нажатие кнопки «сохранить» пользователем вызывает какие-то изменения в БД. Нужно тестировать, что после нажатия этой кнопки пользователь может получить эти данные.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы