![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
О TDD, ретроградстве и варении в собственном соку
По мотивам предыдущего поста про taucraft: решарпер там или не решарпер, но Test-Driven-Development штука (вроде бы) объективно полезная.
При этом я почти уверен, что я TDD не использую, т.к. уже 15 лет занимаюсь всякой хренью в экстренном темпе, тесты у меня все заключаются в "проверить 10 раз чтобы миграция 30 Гб БД прошла успешно" и "отчетность видна от имени пользователя, который ей будет пользоваться".
Правильность же реализации/рефакторинга/замены всего с нуля проверяется за счет двойной записи бухгалтерии, наличия нескольких путей расчета одной и той же цифры и статических гарантий (т.е., например, я никогда не стану делать отчет отдельными запросами по списку аналитических кодов, если его можно сделать одним select/group by, при этом в него нужная аналитика попадет гарантированно). Плюс функциональщина, статические типы, кодогенерация - ну невозможно ошибится в коде, если у тебя источник информации для кода всегда один. А ошибки вида "не так спроектировали" - тестами не лечатся.
Еще я не использую разного рода современные инструменты, версии студии меняю через 2-3 года после их выхода, склонен использовать самодельные компоненты вместо готовых и вообще страдаю ретроградством.
Проблема в том, что у меня совершенно нет критериев оценки, где я прав и пропускаю ненужные buzz-words мимо ушей, а где не прав, и упускаю полезные инструменты. Потому что на всех работах инструменты/платформы/методики работы выбираю я и обсудить этот выбор на адекватном уровне не с кем.
Раньше хотя бы был вменяемый критерий "успеем проект сдать вовремя или не сделаем вообще", а сейчас и он смысл потерял - это вообще перестало зависеть от используемых технологий, а стало зависеть от наличия бабла у клиентов и правильной организации труда.
Т.е. та же проблема, что в любых НИИГиТ - сидит 50летний мега-гуру, всю жизнь варившийся в собственном соку, который уже не в состоянии различить, где бессмысленная гонка за новизной или просто неподходящая технология, а где реально нужно отрывать жопу от стула и менять себе мозг.
При этом я почти уверен, что я TDD не использую, т.к. уже 15 лет занимаюсь всякой хренью в экстренном темпе, тесты у меня все заключаются в "проверить 10 раз чтобы миграция 30 Гб БД прошла успешно" и "отчетность видна от имени пользователя, который ей будет пользоваться".
Правильность же реализации/рефакторинга/замены всего с нуля проверяется за счет двойной записи бухгалтерии, наличия нескольких путей расчета одной и той же цифры и статических гарантий (т.е., например, я никогда не стану делать отчет отдельными запросами по списку аналитических кодов, если его можно сделать одним select/group by, при этом в него нужная аналитика попадет гарантированно). Плюс функциональщина, статические типы, кодогенерация - ну невозможно ошибится в коде, если у тебя источник информации для кода всегда один. А ошибки вида "не так спроектировали" - тестами не лечатся.
Еще я не использую разного рода современные инструменты, версии студии меняю через 2-3 года после их выхода, склонен использовать самодельные компоненты вместо готовых и вообще страдаю ретроградством.
Проблема в том, что у меня совершенно нет критериев оценки, где я прав и пропускаю ненужные buzz-words мимо ушей, а где не прав, и упускаю полезные инструменты. Потому что на всех работах инструменты/платформы/методики работы выбираю я и обсудить этот выбор на адекватном уровне не с кем.
Раньше хотя бы был вменяемый критерий "успеем проект сдать вовремя или не сделаем вообще", а сейчас и он смысл потерял - это вообще перестало зависеть от используемых технологий, а стало зависеть от наличия бабла у клиентов и правильной организации труда.
Т.е. та же проблема, что в любых НИИГиТ - сидит 50летний мега-гуру, всю жизнь варившийся в собственном соку, который уже не в состоянии различить, где бессмысленная гонка за новизной или просто неподходящая технология, а где реально нужно отрывать жопу от стула и менять себе мозг.
no subject
Я тесты могу рассматривать только с точки зрения "я написал тесты и они проверяют что в общем случае от того что я поменял кусок кода в одном месте в другом _вроде_как_ все продолжает работать". Но непонятно.
no subject
Во-первых - элементарные функции тестировать юнит-тестами и рандомно - чтобы они в области определения вели себя хорошо, ошибались предсказуемо и падали с красивыми исключениями либо не падали вообще (пока память не битая и проц на месте).
Во-вторых - архитектура должна быть такой, чтобы комбинирование функций не влияло на них по отдельности никак. Т.е. не должно быть такого, что + в одном вызове работает хорошо, в другом плохо (такое есть на уровне проца и контрольных слов FPU кстати :)). В коде не должно быть неконтролируемых зависимостей.
В третьих - ошибки вида "в десяти разных местах сошлись нехорошо звезды и все ебнулось" крайне редки, обычно совершаются ошибки вида "обработка ошибок сделана через задницу" и "забыли инициализировать переменную".
Это все лечится нормальными системами типов (либо их имитацией на языках, где это невозможно).
no subject
Ну я к тому что даже в случае просто функции которая делает не очень много если заморочиться можно придумать много разных комбинаций параметров, а я, зная себя, понимаю что пока я не напишу все возможные варианты спокойно я спать не буду.
no subject
Я пхпшнег :(
no subject
В этом деле признать проблему -- самое главное.
no subject
no subject
no subject
Я придерживаюсь таких правил:
1. Тестировать только публичные методы.
2. Unit тест тестирует один класс в отрыве от остальных. Архитектура должна это поддерживать.
3. Тесты должны описывать спецификацию системы. 2 + 2 тестировать ни к чему.
Это в первом приближении. Есть ещё куча других тестов и правила у них другие.
no subject
Как же вам таки хорошо жить. А я вот спать не могу )
no subject
Ох жеж блин... :))) это кому-то даже надо отдельным пунктом выносить.
А интересно... а как у вас "тестируют приватные"? :))
\\2. Unit тест тестирует один класс в отрыве от остальных. Архитектура должна это поддерживать.
А то что это следует из определения юнит-теста, оно ниче? :))
Суровые челябинские программисты у вас там... как я погляжу. :) (ну да, сейчас много где так)
no subject
У меня юнит-тесты принадлежат тестируемому классу или тестируемому модулю.
"Ох жеж блин... :))) это кому-то даже надо отдельным пунктом выносить."
Пожалуй надо. Есть эзотерические направления, тестирующие приватные методы.
"А то что это следует из определения юнит-теста, оно ниче? :))"
Ну следует и следует. Не так уже легко это правило планомерно соблюдать.
no subject