Войти
ФлеймФорумПрограммирование

Почему хабр торчит от TDD? (2 стр)

Страницы: 1 2 3 440 Следующая »
#15
15:50, 2 фев. 2013

aloha_hawaii
> а давайте устроим рейд на хабр

Это жалкое и бессмысленное в своей жестокости место того не стоит.

Рейд на тесты можно и тут устроить))

#16
16:09, 2 фев. 2013

Kartonagnick
да тесты нужны, особенно там где их легко написать, кто же спорит. Но фанатичная вера в TDD, сначала напишите тесты а затем код, это уже за гранью добра и зла.  Пока какой-ни буть не тривиальный кусок кода напишешь, все интерфейсы локально может по 3-4 раза переколбасить, фанаты TDD предлагают 3-4 раза переписывать тесты?

#17
16:28, 2 фев. 2013

thevlad
> да тесты нужны, особенно там где их легко написать, кто же спорит. Но
> фанатичная вера в TDD, сначала напишите тесты а затем код, это уже за гранью
> добра и зла.  Пока какой-ни буть не тривиальный кусок кода напишешь, все
> интерфейсы локально может по 3-4 раза переколбасить, фанаты TDD предлагают 3-4
> раза переписывать тесты?


Перефразию: Сначала опишите пример-иллюстрацию использования, а затем только думайте о реализации, но это уже за гранью добра и зла.
Пока какой нибудь не тривиальный кусок реализации напишешь, весь дизайн использования по 3-4 раза можно переколбасить.

Фанаты предлагают 3-4 раза подумать над использованием, и один раз на реализацией?


итого:
Ты сначала подумай, что ты делаешь, и как это будет работать. А потом только делай. Тогда не придется тебе по 3-4 раза все переделывать.

#18
16:47, 2 фев. 2013

Kartonagnick
> сначала подумай, что ты делаешь, и как это будет работать. А потом только
> делай. Тогда не придется тебе по 3-4 раза все переделывать.
Да-да, жители страны эльфов *всегда знают как должно быть с первого раза*, поэтому они там и живут, а при встрече с жестокой реальностью у них случается "разрыв шаблона". Меня всегда восхищали такие синтенции, в духе: "а вы проектируйте лучше..."

#19
16:56, 2 фев. 2013

thevlad
> Да-да, жители страны эльфов *всегда знают как должно быть с первого раза*,
> поэтому они там и живут, а при встрече с жестокой реальностью у них случается
> "разрыв шаблона". Меня всегда восхищали такие синтенции, в духе: "а вы
> проектируйте лучше..."


Житель страны эльфов продумывает дизайн использования, и механику, как можно удостоверится, что сия задумка работает так, как и ожидается.
Он не тратит время на реализацию непойми чего.

При этом, чем четче вырисовывается дизайн, тем лучше становится понятна задача. Иногда дизайн слегка приходится менять. Однако заменить дизайн очень просто. Ведь эльф не тратил времени на нахер не нужную реализацию, которую теперь нужно выбросить в мусорку.

Когда жеж дизайн полностью удовлетворяет эльфу. Только тогда он реализует механизм.

И этот механизм внезапно делает то, что и было нужно эльфу.

И если в последствии, придется слегка изменить дизайн (что редко) - тесты проконтролируют, что изменения ничего нигде не поломают.
На практике: бывает, нужно нарастить дополнительный функционал без изменений в существующем дизайне.


Если нужно изменить дизайн кардинально - это уже разработка другого механизма с совершенно иным дизайном. Фейл архитектора.
Старый можно не мучать, а сразу начинать новый.

#20
17:03, 2 фев. 2013

Kartonagnick
ага, "жители страны эльфов *всегда знают как должно быть с первого раза*", я об этом и написал.
из того что ты пишешь, как раз и получаются "архитектурные астронавты", теперь буду знать что это всего лишь жители страны эльфов столкнувшиеся с TDD

#21
18:14, 2 фев. 2013

thevlad
> ага, "жители страны эльфов *всегда знают как должно быть с первого раза*", я об
> этом и написал.

жители страны эльфов не всегда знают каким будет дезайн с первого раза.
но они его шлифуют. Смысли сам дизайн, а не реализацию.

Таким образом, они не совершают овер-инжениринг, как это делаешь ты, не имея гарантий, что модифицированный не поломал нигде ничего

#22
18:40, 2 фев. 2013

Kartonagnick
> Ты сначала подумай, что ты делаешь, и как это будет работать. А потом только
> делай. Тогда не придется тебе по 3-4 раза все переделывать.
Мне и не приходится.
Спрашивается, на кой черт мне тратить время оборачивая все юнит тестами, если я не собираюсь код менять?

#23
18:54, 2 фев. 2013

Kartonagnick
>Таким образом, они не совершают овер-инжениринг, как это делаешь ты, не имея гарантий, что модифицированный не поломал нигде ничего
я еще раз скажу, что не против делать тесты (там где это рационально) для уже более-менее стабилизировавшихся интерфейсов, но TDD - это переписывание тестов минимум по 3-4 раза.

#24
19:21, 2 фев. 2013

@!!ex
> Мне и не приходится.
> Спрашивается, на кой черт мне тратить время оборачивая все юнит тестами, если я
> не собираюсь код менять?

Вы рассуждаете наизнанку.

Не очень много смысла сначала построить механизм, и отладить его работу, а потом делать тесты.
Все наоборот! Сначала тесты, потом механизм. Тогда это сократит время и на проектирования дизайна, и на отладку, и безопасность для будущих модификаций.

thevlad
> я еще раз скажу, что не против делать тесты (там где это рационально) для уже
> более-менее стабилизировавшихся интерфейсов, но TDD - это переписывание тестов
> минимум по 3-4 раза.

Более-менее стабильным интерфейсам делать тесты поздновато. Они итак уже стабильные. После инжениринга, и отладки.

Программирование через тестирование - сначала тесты (они же юз-кейсы, или "как будет работать"), только потом реализация.


Интересен такой эффект. Бывает так, что не знаешь как именно можно проконтролировать ожидаемое поведение механизма. ВСЕГДА это является изъяном дизайна.

В вашем случае это означает овер-инжениринг, переделка и дизайна, и реализации.

В случае с тестами: если нет возможности сделать простой тест, значит нужно пересмотреть дизайн. Размышлять о дизайне намного проще, и дешевле, чем по десять раз переписывать гору уже написанного кода.

Программирование через тестирование экономит время: дизайн, отладка, сопровождение.

#25
19:45, 2 фев. 2013

jaguard

Для динамиков очень даже нужно...

@!!ex
> Тривиальные проверки и так в коде должны быть, если ты их знаешь - ты их
> навесишь. Тесты нафиг не сплющились.

Тест эта такая клмплексная проверка конечного результата. Запросто могут выполняться все проверки в каждой функции, но в итоге давать неправильный результат :)

#26
19:53, 2 фев. 2013

innuendo, если для отыгрыша ситуации требуется имитировать значительную часть окружения - это серьёзный признак ущербной архитектуры и плохого дизайна.

Такие узлы - уязвимые. Поскольку плохо переносят радикальные правки в масштабе всего архитектурного комплекса.

Если даже подобные ситуации и возникают, лучше изменить дизайн механизма так, что бы отвязать его от остальной части архитектуры (и вот тут тесты очень здорова помогают. Контролируя, что на такой поздней стадии изменения нигде ничего не поломают)

Ну и отвязав компонент от системы, можно уже спокойно менять систему.

Потом запуск тестирования - и все зелененькое.

Тесты здорово помогают вносить изменения в архитектуру всего сооружения, без боязни отказа отдельных компонентов.

#27
20:00, 2 фев. 2013

innuendo
> Запросто могут выполняться все проверки в каждой функции, но в итоге давать
> неправильный результат :)

ПишемТесты();

TDD:

ЗапуститьТесты();
Если тесты прошли успешно,
  Пишем тесты для тестов.    // we need to go deeper!
Иначе
  Печать ("Я же говорил что TDD реально помогает!");

goto TDD;

ПишемРеализацию(); // warning C4702: unreachable code

#28
20:05, 2 фев. 2013

Kartonagnick
> Тесты здорово помогают вносить изменения в архитектуру всего сооружения, без
> боязни отказа отдельных компонентов.
Модульность в этом помогает и отказ от глубоких связей.

#29
20:19, 2 фев. 2013

@!!ex
> Модульность в этом помогает и отказ от глубоких связей

Существует великое множество техник за контролем работы.

Цель каждой - минимизировать количество ошибок и время на отладку. Но ни одна из техник не является серебряной пулей.
Однако комплексное использование приводит к удешевлению продукта.

Программирование с тестами это иллюстрации из-кейсов, и гарант их выполнения.
Отличное решение. Разумеется это не отменяет применение других техник.


Допустим, я использую модульность, каждая функция начинается с ассерт-проверок и бла бла бла.
Мои тесты тестируют не только работоспособность, но и вложенную систему безопасности.
Они гарантируют, что если пользователь прокосячет - будет реакция.


Ещё одно достоинство: комплексное тестирование.

Я называю это "тестирование под условием", ну или "поведение в ситуации".

Иногда, что бы глянуть, что будет, нужно дождаться особой ситуации в игрушке.
На тестах я приказываю механизмам: "ситуация такая: ты сходишь сюда, а ты - сюда. А ты - реагируй!"

Без тестов, если пишешь в лоб, то отдел тестирования, твои лучшие друзья!

В моём случае, я смогу тестировать любые ситуации практически мгновенно.

Страницы: 1 2 3 440 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.