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

Question

[Utter_step]

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

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

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


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

P.S. Основное время программирую на Perl'e и Python'e. Если есть советы конкретно по этим языкам — буду вдвойне благодарен.

Comments

[Utter_step]

Спасибо всем ответившим, что ж, буду пытаться.)

Answer 1

[klen]

Когда не знаешь, в какой момент писать тесты, заведи простую привычку: нашел баг, прежде чем закрыть, покрой тестом который его ловит. При таком подходе с динамическим языком и не заметишь как весь проект тестами обрастет. А потом когда поймешь профиты вполне может сформироваться привычка и склонность к ТДД.

Answer 2

[Stdit]

Тесты нужны в первую очередь в тех местах, которые могут сломаться. Это, как правило, сложнозависимые места. Начинать писать тесты на самом верхнем уровне, например на api модели и http раутинги (если это веб), постепенно спускаясь вниз до разумных пределов. А вообще, в истинном дзен-TDD начала пишутся тесты, а потом уже функциональность под них.

Answer 3

[egorinsk]

Тесты стоит писать для компонент, которые с большой вероятностью легко сломать (и которые вызовут у вас трачу времени на поиск проблемы). Если у вас есть код, выводящий из БД табличку или добавляющий пользователя, или типичный контроллер, или типичная модель, нет смысла его тестировать.

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

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

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

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

А делать тесты ради тестов и 100% покрытия, по моему, глупо. Не забывайте, к примеру, что в случае каких-то изменений в покрытом коде вам, скорее всего, придется еще и переделывать тесты.

Comments

[int03e]

А делать тесты ради тестов и 100% покрытия, по моему, глупо. Не забывайте, к примеру, что в случае каких-то изменений в покрытом коде вам, скорее всего, придется еще и переделывать тесты.

В таком случае лучше изменить тест, а потом переписать код чтобы этот тест не падал. TDD — хорошая практика.

Answer 4

[Глеб Старков]

Прочитай книги о TDD.
Мне, в свое время, очень помогла эта

Answer 5

[Владимир Чернышев]

Мне помог такой подход на существующем коде:
— функциональные/приемочные тесты на новые или изменяемые фичи (по сути описание ТЗ на неком DSL)
— модульные/интеграционные при рефакторинге
— тесты на баги

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