тестирование и жизнь
Мой экспресс-пост про тестирование вызвал бурление мнений.
В частности, меня объявили тестофобом и непрофессионалом. :)
Товарищи. Тесты всякие нужны, тесты всякие важны. Игнорировать их нельзя. Профессиональная разработка БЕЗУСЛОВНО включает в себя тестирование.
Но. Надо понимать, что НИКАКОЙ тест ничего не ГАРАНТИРУЕТ.
Два примера для упорных.
1. Юнит-тесты и TDD.
Выполняя задачу в рамках разработки, пинаемой тестированием (TDD) Бангалорский девелопер закоммитил в транк код функции возведения в степень следующего содержания: "return 4;". Функция успешно прошла юнит-тестирование и принесла детишкам много-много радости на этапе отладки.
Вопросы к фанатам tdd.
q1a: каков был тест для этой функции.
q1b: каков должен быть тест для этой функции. Отдельно показать, почему точность реализации функции будет выше точности реализации теста. (Ответ - нипочему. Оптимальное поведение программиста - скопировать в код функции код теста.)
2. Но, конечно, главный бастион у нас - это регрессы. Полезность и осмысленность регресс-тестов никто не отрицает, они - наше всё. Только надо и тут чётко понимать - НЕ ГАРАНТИЯ.
Один мой знакомый забросил стезю программиста после того, как его перестали допускать до кода проекта. Почему перестали? А он его сломал. И вся остальная команда - включая крайне опытных разработчиков высочайшего класса - несколько дней стучалась головой об стену, пытаясь понять, что за ФЕЕРИЧЕСКИЙ бред творится в коде - причём повсеместно.
Нашли чудом. Благо - проект был небольшой, и код буквально перечитали от начала до конца. (Диффов не было - это 1986-й год, проект под ДОС).
Что же сделал наш кудесник? Поменял два байта.
Было
#define True 1
#define False 0
стало
#define True 1
#define False -1
Автор коммита говорил потом, что так красивее.
q2: покажите регресс-тест из любого вашего проекта, который поймает такое.
В частности, меня объявили тестофобом и непрофессионалом. :)
Товарищи. Тесты всякие нужны, тесты всякие важны. Игнорировать их нельзя. Профессиональная разработка БЕЗУСЛОВНО включает в себя тестирование.
Но. Надо понимать, что НИКАКОЙ тест ничего не ГАРАНТИРУЕТ.
Два примера для упорных.
1. Юнит-тесты и TDD.
Выполняя задачу в рамках разработки, пинаемой тестированием (TDD) Бангалорский девелопер закоммитил в транк код функции возведения в степень следующего содержания: "return 4;". Функция успешно прошла юнит-тестирование и принесла детишкам много-много радости на этапе отладки.
Вопросы к фанатам tdd.
q1a: каков был тест для этой функции.
q1b: каков должен быть тест для этой функции. Отдельно показать, почему точность реализации функции будет выше точности реализации теста. (Ответ - нипочему. Оптимальное поведение программиста - скопировать в код функции код теста.)
2. Но, конечно, главный бастион у нас - это регрессы. Полезность и осмысленность регресс-тестов никто не отрицает, они - наше всё. Только надо и тут чётко понимать - НЕ ГАРАНТИЯ.
Один мой знакомый забросил стезю программиста после того, как его перестали допускать до кода проекта. Почему перестали? А он его сломал. И вся остальная команда - включая крайне опытных разработчиков высочайшего класса - несколько дней стучалась головой об стену, пытаясь понять, что за ФЕЕРИЧЕСКИЙ бред творится в коде - причём повсеместно.
Нашли чудом. Благо - проект был небольшой, и код буквально перечитали от начала до конца. (Диффов не было - это 1986-й год, проект под ДОС).
Что же сделал наш кудесник? Поменял два байта.
Было
#define True 1
#define False 0
стало
#define True 1
#define False -1
Автор коммита говорил потом, что так красивее.
q2: покажите регресс-тест из любого вашего проекта, который поймает такое.