QA – грамотно

Сотоварищи из харьковского подразделения GlobalLogic сотворили “Поэму о юнит-тестах“:

У нас, в харьковском GlobalLogic’е, появилась традиция: проводим мы неформальные сходки, обсуждаем темы околоайтишные… На одной из таких сходок, посвященной Agile/не Agile процессам, встал вопрос Unit Test’ов. Оказывается, модульное тестирование выглядит очень просто в примерах из книг, но когда мы начинаем применять его на проектах, которые достались нам по наследству, на проектах с нетривиальной многоуровневой архитектурой, тут же сталкиваемся с проблемами.

Похвально не то, о чем, а то, как это преподнесено.

Если пишешь код — пиши тесты

Ученик спросил мастера-программиста:

“Когда я могу перестать писать тесты?”

Мастер ответил:

“Когда ты перестаешь писать код”

Ученик спросил:

“Когда я перестаю писать код?”

Мастер ответил:

“Когда ты становишься менеджером”

Ученик задрожал и спросил:

“Когда я становлюсь менеджером?”

Мастер ответил:

“Когда ты перестаешь писать тесты”

Ученик побежал писать тесты.

Остались только следы.

Если код заслуживает быть написанным, он заслуживает иметь тесты.

Не застряньте в догме юнит тестирования

Догма говорит:

“Делай это.
Делай только это.
Делай это только так.
И делай это потому, что я тебе говорю”

Догма не гибкая.

Тестированию нужна гибкость.
Догма убивает творчество.

Тестированию нужно творчество.

Примите карму юнит-тестов

Карма говорит:

“Делай хорошие вещи, и хорошие вещи произойдут с тобой.
Делай их так, как ты знаешь.
Делай их так, как тебе нравится”.

Карма гибка.

Тестированию нужна гибкость.

Карма процветает на творчестве.

Тестированию нужно творчество.

Единственный минус – кроме литературы в статье есть только заголовки будущих разделов

Для вопросов

• Почему нужно тестировать?
• Что тестировать, а что нет?
• Сколько должно быть тестов?
• Как писать хорошие тесты?
• Затрагивает ли написание тестов архитектурные вопросы?
• Как быть, если мы сопровождаем старый код?

ответы еще не написаны.