• бла,
• бла-бла,
• бла-бла-бла,
• бла-бла-бла-бла…

Таким образом можно обеспечить процесс…“

Типичный диалог

который следует далее:

- Вам, ребята, неплохо было бы перейти на юнит-тесты. Вы ведь знаете, что такое юнит-тесты?

- Ну, наверное… Только мы и так не успеваем, а тут еще и тесты писать придется отдельно…

- Да нет же! Это не те тесты! Это те тесты, которые пишутся ПЕРЕД тем, как пишется код. Понятно?

- Нет.

- Ну, блин… Вот, перед тем, как заимплементить фичу на стэйджинге*, ты лабаешь код, который будет ее проверять. Понятно?

* Юзаем спецязык, шоб не думали, что мы тут лаптем шиты; “не соло, но хлебавши” ©.

- Ну, кагбэ…

- Вот! Вот! И это позволяет нам избежать следующих рисков:

• бла,
• бла-бла,
• бла-бла-бла,
• бла-бла-бла-бла,
• дынь-дынь-дынь-дынь,
• бул-бул-бул-бул-бул-шит…

- Ну хорошо, но… Как это делать?

- Ну, я же не знаю, это же ваша область ответственности; вы и решайте.

- Нда. Ладно, мы подумаем (о чем-нибудь другом).

Резюме

Юнит-тесты – это не просто хорошо.

Это иногда очень хорошо, ЕСЛИ программисты умеют это делать.

Если умеют, то и говорить не о чем.

Если не умеют, то тот, кто приносит инициативу, предварительно должен научиться эти самые юнит-тесты писать и переписывать. Иначе будет фэйл.

Я на этот фэйл когда-то отлично напоролся, повторять не рекомендую.

Будут воспринимать как неадекватного, и будут правы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Карма гибка.

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

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

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

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

Для вопросов

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

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