Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
вы несколько абзацев описывали, что нужно тестировать, но так и не сказали, что тестировать надо всю логику в проекте.
интересное имя у метода — TestDoSomething — вы правда их так называете?
интересное имя у метода — TestDoSomething — вы правда их так называете?
Про то, что надо тестировать логику, уже до меня написали умные люди.
TestDoSomething — обижаете :)
TestDoSomething — обижаете :)
ну так и пишите нормальные названия сразу:)
все очень просто — допустим, что я не знаю что такое TDD. читаю ваш пост.
думаю: «блин, TDD — это ведь клевая штука. надо использовать» (вы ведь ради таких мыслей читателей пост писали?)
и буду ориентироваться на вашу статью, как на источник моей увлеченности. и буду повторять ваши name conventions. и что из этого выйдет?
все очень просто — допустим, что я не знаю что такое TDD. читаю ваш пост.
думаю: «блин, TDD — это ведь клевая штука. надо использовать» (вы ведь ради таких мыслей читателей пост писали?)
и буду ориентироваться на вашу статью, как на источник моей увлеченности. и буду повторять ваши name conventions. и что из этого выйдет?
Да хоть 1000 причин писать можно… Кто-нибудь напишет 1000 причин почему это все фигня! Холивар идет давно и конца и края нет.
Помоему для некоторых tdd- это такая магическая мантра, типа html5. Вот придет комунизм и будет всем хорошо.
Тесты писать можно много и разных. Часто я пишу тесты возможно и в стиле MyClass, TestMyClass… эти тесты ни unit(тк нет ни каких моков, ибо нечего захламлять код и писать оберток на порядок больше чем рабочего кода) и это не пользовательские тесты, они скорее интеграционные, не содежат пользовательской истории( тк ее можно в 1 метод запихать, а реально тестов может быть вагон)
но Я ЧЕРЕЗ НИХ ОТЛАЖИВАЮСЬ В ДЕБАГЕРЕ.
Создал метод, вызвал его и по шагово смотришь что происходит. В итоге на выходе ты уже знаешь как должен себя корректно вести этот код на этом тесте.
Есть код, есть тест.
Да не феншуй, да не tdd… Но работает. Я думаю у каждого кто пишет хоть какие-то тесты осознано есть такие практики.
Те кто пишет тесты чтобы было- это отдельный разговор.
Помоему для некоторых tdd- это такая магическая мантра, типа html5. Вот придет комунизм и будет всем хорошо.
Тесты писать можно много и разных. Часто я пишу тесты возможно и в стиле MyClass, TestMyClass… эти тесты ни unit(тк нет ни каких моков, ибо нечего захламлять код и писать оберток на порядок больше чем рабочего кода) и это не пользовательские тесты, они скорее интеграционные, не содежат пользовательской истории( тк ее можно в 1 метод запихать, а реально тестов может быть вагон)
но Я ЧЕРЕЗ НИХ ОТЛАЖИВАЮСЬ В ДЕБАГЕРЕ.
Создал метод, вызвал его и по шагово смотришь что происходит. В итоге на выходе ты уже знаешь как должен себя корректно вести этот код на этом тесте.
Есть код, есть тест.
Да не феншуй, да не tdd… Но работает. Я думаю у каждого кто пишет хоть какие-то тесты осознано есть такие практики.
Те кто пишет тесты чтобы было- это отдельный разговор.
тут холиваров никаких нет. TDD работает — это факт. экономит время и повышает качество.
если вас эта методика не интересует и вы нашли удобный для вас способ работы — ваше право, ваше дело и ваши деньги.
как себя мотивировать использовать TDD? да никак, оставайтесь с вашей методикой.
если вас эта методика не интересует и вы нашли удобный для вас способ работы — ваше право, ваше дело и ваши деньги.
как себя мотивировать использовать TDD? да никак, оставайтесь с вашей методикой.
Про «Не TDD» здесь речи не было, ведь этот блог про TDD. А дебаггером я и сам пользуюсь.
так через TDD как раз и пытаются избавиться от таких вещей, как отладка в дебагере. Когда проект становится большим, то дебагер становится непозволительной роскошью и оружием точечного воздействия. Возможно, что вы делаете что-то не так.
Правильно написанные unit-тесты почти никогда не требуют отладки в дебагере. Интеграционные тесты тоже нужны, но и в них использовать дебагер не рекомендуется.
Возможно вы пересмотрите свое отношение и почитаете немного на эту тему, т.к. правильное понимание TDD облегчит вам жизнь.
Правильно написанные unit-тесты почти никогда не требуют отладки в дебагере. Интеграционные тесты тоже нужны, но и в них использовать дебагер не рекомендуется.
Возможно вы пересмотрите свое отношение и почитаете немного на эту тему, т.к. правильное понимание TDD облегчит вам жизнь.
Вы — это я.
Вердикт: пишем тесты после кода только в тех случаях, когда надо по-быстрому срубить денег, не особо волнуясь о последствиях.
То есть вы утверждаете, что написание тестов после кода как-то экономит время по сравнению с применением методики TDD?
Это в корне неверно: пишете тест после кода -> видите недостатки дизайна -> исправляете дизайн => тратите дополнительное время; с TDD вы видите недостатки дизайна сразу, даже не успевая зачастую написать эти недостатки.
Про какую-то экономию времени в случаях «быстро срубить бабла» можно говорить только если вы вообще не пишите тестов — когда у вас куплен билет на самолет в одну сторону в какую-нибудь экзотическую страну, где заказчик вас точно не достанет. в других случаях проект без тестов — это как машина без страховки на оживленной трассе с кучей водителей-новичков, лихачей и новичков-лихачей.
Абсолютно согласен. Экономия времени только в том, что мы, на самом деле, тестов писать не будем, а быстро убежим.
Написание тестов после кода может экономить время по сравнению с их не написанием вообще. То есть сценарий разработки может быть примерно таким: получаете задание -> пишите код -> получаете деньги -> получаете частично изменившееся задание -> пишите тесты, фиксирующие поведение не изменяющейся части -> пишите код изменяющейся части, будучи уверены, что с большой вероятностью не изменяющаяся часть не сломалась -> получаете деньги (а не претензии: «новая фича реализована отлично, но всё остальное перестало работать!»).
Собственно что непонятного? Грубо говоря, перед тем, как написать, изменить или удалить не «пустую» строчку кода, пишем тест, который проверяет, что строчка действительно будет написана, изменена или удалена.
Когда вы пишете строчку кода у вас, надеюсь :), есть для этого причина — нереализованная функциональность или функциональность, которую надо реализовать. При традиционной разработке вы держите эту причину в голове или туду-листе каком-нибудь, более-менее представляя, надеюсь :), что будет делать код, который вы сейчас напишите, затем пишите код, затем, может-быть, как-то (тестами, ручками, через вайн и багрепорты пользователей)проверяете, что он действительно делает то, что вы представляли. Потом решаете сделать рефакторинг, делаете и как-то проверяете, что ничего не сломалось.
При TDD вы не просто представляете, что будет делать код, а пишите тест, который проверяет, что он действительно это делает, запускаете тест, убеждаетесь, что тест не проходит (кода-то ещё нет), пишете код, убеждаетесь, надеюсь :), что тест проходит и делаете, при необходимости, рефакторинг, опять запускаете тесты, убеждаясь, что ничего не сломалось.
По сути TDD это цикл:
— формализация требований
— проверка, что требования ещё не выполнены
— реализация требований
— проверка, что реализация требования выполняет
— оптимизация реализации при необходимости
— проверка, что оптимизированная реализация требования выполняет.
Этот цикл так или иначе вы всё равно выполняете при разработке (иногда совмещая реализацию и оптимизацию, что не есть best practice), но при TDD инструментом формализации требований и проверки их выполнения реализацией служат тесты, а не что-то иное. Остальное детали использования инструментом.
Когда вы пишете строчку кода у вас, надеюсь :), есть для этого причина — нереализованная функциональность или функциональность, которую надо реализовать. При традиционной разработке вы держите эту причину в голове или туду-листе каком-нибудь, более-менее представляя, надеюсь :), что будет делать код, который вы сейчас напишите, затем пишите код, затем, может-быть, как-то (тестами, ручками, через вайн и багрепорты пользователей)проверяете, что он действительно делает то, что вы представляли. Потом решаете сделать рефакторинг, делаете и как-то проверяете, что ничего не сломалось.
При TDD вы не просто представляете, что будет делать код, а пишите тест, который проверяет, что он действительно это делает, запускаете тест, убеждаетесь, что тест не проходит (кода-то ещё нет), пишете код, убеждаетесь, надеюсь :), что тест проходит и делаете, при необходимости, рефакторинг, опять запускаете тесты, убеждаясь, что ничего не сломалось.
По сути TDD это цикл:
— формализация требований
— проверка, что требования ещё не выполнены
— реализация требований
— проверка, что реализация требования выполняет
— оптимизация реализации при необходимости
— проверка, что оптимизированная реализация требования выполняет.
Этот цикл так или иначе вы всё равно выполняете при разработке (иногда совмещая реализацию и оптимизацию, что не есть best practice), но при TDD инструментом формализации требований и проверки их выполнения реализацией служат тесты, а не что-то иное. Остальное детали использования инструментом.
Троли такие троли
Да при чем здесь троли?! просто TDD действительно непонятная хня! к примеру, если надо написать клас Array, то здесь TDD ложится хорошо. А если надо реализовать выборку supplementary feature из core entity, учитывая facility setting, то здесь хуя, а не TDD, поскольку тебе надо разобраться во всей этой белиберде потыкать, пощупать и тогда уже писать код, какие тесты изначально? Здесь, тоже все понятно, каждая вещь имеет свою область применения. Беда в другом. Наши ж бля начитаются вумных книжок и начинают тыкать это TDD куда ни попадя.
hazzik тролит. Возможно, как раз с целью получить комментарии вроде вашего. Ваш комментарий, скорее, обличает вас, нежели TDD. Без обид. TDD — не панацея, TDD для некоторого кода применять довольно сложно, но сказать в подтверждение непонятности TDD, что вот какая у меня сложная система, вот какие умные английские слова я знаю, да еще и попутно опустив коллег по цеху — это просто несерьезно.
А в чем, простите обличает?!
«но сказать в подтверждение непонятности TDD»: я хоть что-то сказал в отличие от ...! от вас же кроме минуса никаких аргументов пока нет!
И никого, кроме вас, я не опускал, никого ТРОЛЯМИ не обзывал!
«но сказать в подтверждение непонятности TDD»: я хоть что-то сказал в отличие от ...! от вас же кроме минуса никаких аргументов пока нет!
И никого, кроме вас, я не опускал, никого ТРОЛЯМИ не обзывал!
А в чем, простите обличает?!В некомпетентности. Вы в подтверждение провокационной фразы приводите общие фразы, которые навскидку говорят не о проблемах с TDD, а о вашем неумении его готовить. Если вы сможете аргументировать, почему приведенные вами причины делают TDD тем, чем его назвал hazzik, я возьму свои слова обратно.
т вас же кроме минуса никаких аргументов пока нет!> Вы неправы в своей категоричности и слабой аргументации, но минус я вам не ставил.
И никого, кроме вас, я не опускал, никого ТРОЛЯМИ не обзывал!Да загляните вы уже к нему в профиль :) Это не обзывательство — это факт. Трава зеленая, небо голубое, hazzik — троль.
«Вы в подтверждение провокационной фразы приводите общие фразы, которые навскидку говорят не о проблемах с TDD, а о вашем неумении его готовить. Если вы сможете аргументировать, почему приведенные вами причины делают TDD тем, чем его назвал hazzik, я возьму свои слова обратно» — реально, чувак, я тебя второй раз не понимаю! ты бы не мог высказываться попроще?!
— Вердикт: пишем тесты после кода только в тех случаях, когда надо по-быстрому срубить денег, не особо волнуясь о последствиях.
Я бы так не сказал. Если проект немаленький, есть тестеры, то написание тестов + мок-данные из методов позволяют начать тестирование, когда код еще не готов. Так что девелоперы получат фитбэк еще не написав код. Что делает разработку (иногда) быстрее.
Я бы так не сказал. Если проект немаленький, есть тестеры, то написание тестов + мок-данные из методов позволяют начать тестирование, когда код еще не готов. Так что девелоперы получат фитбэк еще не написав код. Что делает разработку (иногда) быстрее.
А у меня проблема — в тестах я делаю гораздо больше ошибок, чем в коде ((((
Тесты помогают разработать правильную архитектуру, если следовать одному простому правилу: если у вас не получилось без лишних извратов протестировать модуль — меняйте дизайн. Таким образом правильный модуль будет иметь наименьшее число зависимостей от внешних факторов.
Тесты помогают разработать правильную архитектуру, если следовать одному простому правилу: если у вас не получилось без лишних извратов протестировать модуль — меняйте дизайн. Таким образом правильный модуль будет иметь наименьшее число зависимостей от внешних факторов.
На первом месте — хронологически или по важности?
Конечно, TDD работает только в связке с другими элементами. Без осмысления требований как можно тест написать? Но он и помогает лучше требования эти понять, в том числе и самому заказчику.
«лазанья-код (слоеный такой код) толком не тестируется юнит-тестам, только интеграционными»
А если мы используем TDD, откуда взяться лазанья-коду? Вот если у нас Архитектор решил, что мы будем все делать слоями, а потом вручил эту идею горе-программистам, то вот, у нас получился лазанья-код.
Конечно, TDD работает только в связке с другими элементами. Без осмысления требований как можно тест написать? Но он и помогает лучше требования эти понять, в том числе и самому заказчику.
«лазанья-код (слоеный такой код) толком не тестируется юнит-тестам, только интеграционными»
А если мы используем TDD, откуда взяться лазанья-коду? Вот если у нас Архитектор решил, что мы будем все делать слоями, а потом вручил эту идею горе-программистам, то вот, у нас получился лазанья-код.
Да, моки — самая сомнительная часть всего этого.
Но пока что ничего лучшего элита не придумала.
Но пока что ничего лучшего элита не придумала.
TDD ориентирован на использование с самого начала разработки.
Если же вначале кое-как написать прототип, то внедрить туда TDD становится нереально.
Если же вначале кое-как написать прототип, то внедрить туда TDD становится нереально.
Писать о пользе TDD/BDD — это сейчас модно, стильно, молодежно? Ну надоели уже. Те, кто хотел — уже все для себя решили.
Нет, я не противник TDD. Я просто считаю его таким же самым инструментом, как и все остальное и применяю его я тогда, когда это уместно.
Нет, я не противник TDD. Я просто считаю его таким же самым инструментом, как и все остальное и применяю его я тогда, когда это уместно.
Не совсем понял, в статье под «пользовательскими» тестами имеются ввиду Acceptance testing или интеграционные?
Я, кстати, специально об этом писал, что это совсем другая история. Вкрадце, под пользовательскими я понимаю тесты, которые пишутся, исходя из пользовательских историй. На каждый сценарий тут один тестовый класс. Девелоперские тесты пишутся, исходя из девелоперских же представлений об устройстве программы. На каждый класс тут тестовый класс, на каждый метод тут тестовый метод. Возникает иллюзия, что юнит тесты — девелоперские, а пользовательские — интеграционные, но это не так. Надеюсь в будущем написать пост на эту тему.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тесты разные важны, а иные не нужны