...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
01.10.11 16:19: Перенесено модератором из 'О жизни' — AndrewVK
Здравствуйте, DorfDepp, Вы писали:
DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
Самая базовая защита от примитивных багов и опечаток.
Я сам не писал до сих пор тесты. Но в ходе работы были мысли о том, когда они могут сыграть роль.
Например, ты разрабатываешь большой класс, с большим функционалом и что самое главное взаимосвязями.
Через некоторое время становится тяжело держать в голове все эти взаимосвязи и соответственно ты не осознаешь в каком месте новая фича вызовет некорректную работу предыдущего кода. В это случае ты вызываешь свой набор(их может быть много) тестов и проверяешь не уронили ли твои новые две строчки кода твой класс в месте, который ты написал месяц назад (и потестил). При условии отсутствия тестов, тебе на каждые новые две строчки кода придется заново все тестировать вручную, что в некоторых случаях проблематично или очень проблематично или невозможно.
Если ты пишешь кнопочку, то тестировать ее сильно не надо, а вот если пишешь софт для самолета, то тут цена ошибки сам понимаешь высока. И возможно набор тестов сможет уберечь от ошибки. Гарантии 100 процентов конечно нет.
Здравствуйте, HolyNick, Вы писали:
HN>Я сам не писал до сих пор тесты. Но в ходе работы были мысли о том, когда они могут сыграть роль. HN>Например, ты разрабатываешь большой класс, с большим функционалом и что самое главное взаимосвязями.
У меня такие же мысли. Если логика кода очень сложная и путаная, тогда и только тогда тесты могут пригодиться.
А насчет большого класса, не пахнет ли тут антипаттерном, а именно "God object", то есть, один огроменный класс, который делает чуть ли не все вообще? Так лучше его распилить на самостоятельные части и работать станет проще.
HN>Если ты пишешь кнопочку, то тестировать ее сильно не надо, а вот если пишешь софт для самолета, то тут цена ошибки сам понимаешь высока. И возможно набор тестов сможет уберечь от ошибки. Гарантии 100 процентов конечно нет.
DD>А насчет большого класса, не пахнет ли тут антипаттерном, а именно "God object", то есть, один огроменный класс, который делает чуть ли не все вообще? Так лучше его распилить на самостоятельные части и работать станет проще.
Архитектура отдельная песня. Но ключевая проблема — большое число тяжело отслеживаемых связей (которые могут присутствовать даже при хорошей архитектуре).
PS: Просто при плохой архитектуре вообще обалдеешь вносить(безошибочно) какие-то изменения.
Здравствуйте, DorfDepp, Вы писали:
DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
А кто сказал, что они на практике ничего не ловят? У нас периодически что-то ловят.
А для описанных тобой проблем есть автоматические интеграционные тесты, которые у нас тоже ловят и ещё как!
Здравствуйте, HolyNick, Вы писали:
HN>Если ты пишешь кнопочку, то тестировать ее сильно не надо, а вот если пишешь софт для самолета, то тут цена ошибки сам понимаешь высока.
Насколько я знаю, жизненно критический код пишется (ну или должен писаться) совсем по другому, подход к написанию более формальный и математический. Тестами все случаи покрыть в большинстве случаев в принципе невозможно.
Здравствуйте, RiNSpy, Вы писали:
RNS>Насколько я знаю, жизненно критический код пишется (ну или должен писаться) совсем по другому, подход к написанию более формальный и математический.
Что Вы имеете ввиду под "более формальными и математическими подходами"? Насколько они заменяют\отменяют тестирование?
Здравствуйте, HolyNick, Вы писали:
HN>Здравствуйте, RiNSpy, Вы писали:
RNS>>Насколько я знаю, жизненно критический код пишется (ну или должен писаться) совсем по другому, подход к написанию более формальный и математический.
HN>Что Вы имеете ввиду под "более формальными и математическими подходами"? Насколько они заменяют\отменяют тестирование?
Теоретически — заменяют и отменяют полностью.
На практике, конечно, тесты всё равно нужны — хотя бы чтобы проверить, что оборудование и среда продолжают соответствовать тем теоретическим условиям, из которых производилась формальная верификация. Но если предположить, что они соответствуют, то тесты излишни.
Здравствуйте, DorfDepp, Вы писали:
DD>У меня такие же мысли. Если логика кода очень сложная и путаная, тогда и только тогда тесты могут пригодиться.
И главное тут — определить смысл слова "очень". Как у Остёра: 4 — это куча или ещё не куча?
Вот, например, это "очень" или нет?
get_evts(All) ->
%%% SELECT category, level, MIN(timestamp) FROM events \
%%% GROUP BY category,level
%%% NB: input is already sorted literally
lists:reverse(rec_get_evts([], All)).
rec_get_evts(Out, []) ->
Out;
rec_get_evts([{C,L,T1}|ORest], [{C,L,_,T2}|IRest]) when T1 > T2 ->
rec_get_evts([{C,L,T2}|ORest], IRest);
rec_get_evts([{C,L,T1}|ORest], [{C,L,_,_T2}|IRest]) ->
rec_get_evts([{C,L,T1}|ORest], IRest);
rec_get_evts(Out, [{C,L,_,T}|IRest]) ->
rec_get_evts([{C,L,T}|Out], IRest).
Я нарисовал на него тесты, начиная с самых простых (на входе пустой список) и до путаных входных ситуаций, и я спокоен.
DD>А насчет большого класса, не пахнет ли тут антипаттерном, а именно "God object", то есть, один огроменный класс, который делает чуть ли не все вообще? Так лучше его распилить на самостоятельные части и работать станет проще.
IMHO, всегда найдётся что-то, в чём не уверен, даже в достаточно простом классе.
А тесты — они внешняя для разработчика гарантия (хотя бы частичная), что он не ошибся.
Кстати, при чём тут класс? Вот у меня тут вообще классов как таковых не бывает (хотя есть некоторые приближения к тому, что называют этим словом в Simula/SmallTalk/etc.)
Здравствуйте, DorfDepp, Вы писали:
DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
Здравствуйте, DorfDepp, Вы писали:
DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
Рассмотри проблему с обратного конца.
Прежде, чем писать текст метода, напиши, как ты будешь этот метод использовать.
Это и будут unit-тесты.
Это — не тестирование. Это разработка (через тестирование).
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Рассмотри проблему с обратного конца. LVV>Прежде, чем писать текст метода, напиши, как ты будешь этот метод использовать. LVV>Это и будут unit-тесты. LVV>Это — не тестирование. Это разработка (через тестирование).
Часто один метод юзается в 1-2 местах. Это никак нельзя назвать юнит-тестированием. Ты, кстати, сам пробовал так делать?
Здравствуйте, lozzy, Вы писали:
L>Здравствуйте, LaptevVV, Вы писали:
LVV>>Рассмотри проблему с обратного конца. LVV>>Прежде, чем писать текст метода, напиши, как ты будешь этот метод использовать. LVV>>Это и будут unit-тесты. LVV>>Это — не тестирование. Это разработка (через тестирование).
L>Часто один метод юзается в 1-2 местах. Это никак нельзя назвать юнит-тестированием. Ты, кстати, сам пробовал так делать?
Да. Реально помогает нюансы выяснить.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Рассмотри проблему с обратного конца. LVV>Прежде, чем писать текст метода, напиши, как ты будешь этот метод использовать. LVV>Это и будут unit-тесты. LVV>Это — не тестирование. Это разработка (через тестирование).
Во-первых, TDD и юнит-тесты, это вовсе не одно и то же.
Во-вторых, в TDD скорее функциональные тесты основную рояль играют, а не юнит.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, DorfDepp, Вы писали:
DD>>У меня такие же мысли. Если логика кода очень сложная и путаная, тогда и только тогда тесты могут пригодиться.
M>Если логика работы сложная и запутанная, то обычно частями ее проверить сложно, только все целиком и полностью. А это как-бы уже не unit-тест. :)
Вот в этой книге:
хорошо и подробно объясняется, как превратить такой код в легко проверяемый, вплоть до того, что всё покрывается юнит-тестами. А если вы этого не делаете, то таки да, легко не будет.
Здравствуйте, DorfDepp, Вы писали:
DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
Говорят, они хороши, когда уже сильно потом класс ковыряешь. Подковырнул, тесты-то и посыпались, сидишь, чешешь репу
Только эта полезность произойдет лишь если интерфейс класса остается обратно совместимым. А иначе придется еще и тесты ковырять, не только класс.
