Думаю, это будет простая заметка и объяснение, без придирчивых преобразований, но та самая мысль о том, что TDD научил меня мыслить по-другому — правда. Но в итоге, это привело к тому, что я отказался от него.
Давным давно, в 2009 году, прослышав о TDD я решил внедрить его в команду, будучи даже не тимлидом. Надо мной посмеялись и сказали: ну, давай, попробуй.
И я честно пытался. Итого над своим кодом я порой думал несколько часов и писал почти идеальный код (ну, вы же понимаете). В итоге, все придирки от ревьюверов было «ну, тут можно же вот так и вроде норм».
И это был чэллендж, брошенный самому себе. И я его выполнил в течение месяца. И научился писать код, который легко покрывал все мои тесты TDD.
Как я пишу функцию. Начнем с сложения двух чисел:
Хм, но ведь всякое бывает.
Да, но это же не все…
Но блин, это ведт тоже не все…
Вот, теперь кажется все.
К чему я это? А, да. Не доверяй входящим переменным.
И не доверяй возвращаемым переменным. Не до фанатизма, но все-таки.
Тесты могут поменять. И при этом проверять будешь не ты, а кто-то другой, который даже не увидит ошибку: не во всех проектах выделяют 2 часа на ревью.
Со временем я перестал писать тесты от слова совсем, но я всегда и исключительно всегда спрашивал: ты уверен что там придет число? Или не null? А вдруг это будет что-то иное? А если функция вернет тебе ошибку или еще какую-нибудь дичь?
Да, не любили, да, боролись, а потом приняли в паре ошибок и понеслось.
Не верьте входящим переменным, не верьте результату и код будет сложноватым, но безопасным.
Давным давно, в 2009 году, прослышав о TDD я решил внедрить его в команду, будучи даже не тимлидом. Надо мной посмеялись и сказали: ну, давай, попробуй.
И я честно пытался. Итого над своим кодом я порой думал несколько часов и писал почти идеальный код (ну, вы же понимаете). В итоге, все придирки от ревьюверов было «ну, тут можно же вот так и вроде норм».
И это был чэллендж, брошенный самому себе. И я его выполнил в течение месяца. И научился писать код, который легко покрывал все мои тесты TDD.
Как я пишу функцию. Начнем с сложения двух чисел:
function calc(a,b){
return a+b;
}
Хм, но ведь всякое бывает.
function isNumber(n){
return Number(n);
}
function calc(a,b){
return isNumber(a)+isNumber(b);
}
Да, но это же не все…
function isNumber(number){
const n = parseInt(number, 10);
const result = !isNaN(n) && isFinite(n);
return result && n;
}
function calc(a,b){
const newA = isNumber(a);
const newB = isNumber(b);
if (typeof(newA)==="number" && typeof(newB)==="number"){
return a+b;
}
return null;
}
Но блин, это ведт тоже не все…
function isNumber(number){
n = parseInt(number, 10);
const result = n.toString()===number.toString() && !isNaN(n) && isFinite(n);
return result && n;
}
function calc(a,b){
const newA = isNumber(a);
const newB = isNumber(b);
if (typeof(newA)==="number" && typeof(newB)==="number"){
return a+b;
}
return null;
}
Вот, теперь кажется все.
К чему я это? А, да. Не доверяй входящим переменным.
И не доверяй возвращаемым переменным. Не до фанатизма, но все-таки.
Тесты могут поменять. И при этом проверять будешь не ты, а кто-то другой, который даже не увидит ошибку: не во всех проектах выделяют 2 часа на ревью.
Со временем я перестал писать тесты от слова совсем, но я всегда и исключительно всегда спрашивал: ты уверен что там придет число? Или не null? А вдруг это будет что-то иное? А если функция вернет тебе ошибку или еще какую-нибудь дичь?
Да, не любили, да, боролись, а потом приняли в паре ошибок и понеслось.
Не верьте входящим переменным, не верьте результату и код будет сложноватым, но безопасным.
Zibx
Какой это язык?
Если js, то TDD отлично заметит что константа newA объявлена дважды и что функции typeOf нет.
Coverage утилиты способны заставить пройти по всем ветвлениям в коде.
Тесты для корнер кейсов должны писать тестировщики.
TDD — договорённость о том что делает функция до её реализации.
TDD стоит рассматривать как ТЗ на техническом языке.
Бонусом тесты начнут отваливаться когда изменится кусок кода, который «вроде ни на что не повлияет». Даже при горящих сроках разработки — я никогде не жертвую написанием тестов критического функционала.
DSL88 Автор
Да, JS. В принципе, в плане newA — код просто не соберется из-за одинакового имени (опечатка, простите, как и с typeOf) — notepad и пиво делают плохие вещи с людьми (я на бенче, мне можно).
TDD быстро меняется: вы написали функцию, по TDD, а потом пришел другой, поменял функцию и тест (хуже, если не поменял тест), запушил и его кто-то заапрувил (так бывает). А потом вы прогоняете по тестам и пытаетесь вычислить кто это был. По нормальному — код нельзя заапрувить, если он не прошел тесты, поэтому кто-то подменяет красиво тест и он проходит (и апрувит кто-то другой).
На начале вид «TDD стоит рассматривать как ТЗ на техническом языке» прокатывает, но в процессе все радостно кладут на него толстый и жирный Ъ — смотрите правде в глаза. И честно, если команда одна и центролизирована, что бывает не часто — это исправляется палкой по голове, то в больших командах это ничерта не работает.
Я не жертвую тестами, но я уже давно им не доверяю. Это было бы прекрасно только если бы тесты были в другом репозитарии, но мало кто так делает.
P.S.: fixed. Кстати, там был еще больший баг в плане возврата из функции и код бы упал, но вы не заметили ;-)