Ответ 1

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

TDD фактически воплощает это в некоторой степени.

Чтобы написать тест, который вам сначала нужно знать, - чтобы выразить все очень просто: какие будут ваши входы и какими будут ваши ожидаемые результаты.

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

Это то, что мы ранее называли "инженерами требований" и "системным анализом" в старом методе (методах) водопада.

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

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

Для современных практикующих "Agile" методы признать, что они занимаются серией "водопадов", я думаю, слишком смущаю, поэтому эта потребность в разработке требований и понимании затуманивается за языком, который говорит о необходимости обращайтесь к этим вещам, отчаянно пытаясь признать, что "Agile" (как это обычно понимают или, возможно, неправильно понимают) бросают ребенка с большой частью ванны.

Ответ 2

Итак, насколько мне известно, у меня есть письменные модульные тесты, но я нахожу себя сначала начнем писать код вместо написания теста. я чувствую есть мысль/дизайн/парадигма которое действительно огромно. Так, хотя один действительно верит в TDD, вы на самом деле в конечном итоге возвращается старый стиль из-за временного давления/проекта ожидаемые результаты.

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

У меня есть несколько классов, где у меня чистое модульный протестированный код, но я не могу показаться продолжить процесс, когда издевается приходят в картину. Кроме того, я вижу раз: "Не слишком ли тривиально писать тест для этого" синдрома.

Мошки - это одно: вы еще хороши в них? Если вам не нравятся макеты, и вы находитесь в ситуации, когда макеты подходят, тогда практикуйте до тех пор, пока, как TDD, вы не добьетесь успеха.

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

Ответ 3

Это просто:

By learning to think about the "What" __before__ you think about the "How"

Другими словами, подумайте о том, что именно вы хотите делать (интерфейс), а не как, который вы собираетесь сделать (реализация)

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

Итак, в следующий раз, когда вы пробуете "TDD", спросите себя, что именно вы пытаетесь сделать, и просто начните писать код, который выражает ваше намерение.

Пример:

Скажем, кто-то хочет, чтобы вы записали их целым сумматором.

Человек, у которого нет умения TDD, просто сделает:

int add(int a, int b)
{
  return a + b;
}

Правильно ли указан вышеуказанный код? Конечно да. Но этот подход, основанный на моем опыте, терпит неудачу, когда у вас есть сложный компонент для записи. (Вот почему вы задали этот вопрос в первую очередь, я знаю, я был там раньше (возможно, еще? Lol))

Самое замечательное в TDD заключается в том, что он заставляет вас в первую очередь уделять внимание интерфейсу (тому, что) системы, не спрашивая вас сразу о реализации (как).

Другими словами, если кто-то попросил меня написать сумматор, у меня было бы что-то вроде:

void assertOnePlusTwoEqualThree()
{
  assert( add(1,2) == 3 );
}

Обратите внимание, что даже до того, как даже подумать о том, как должен работать add(), я уже несколько разузнал. То есть, я уже понял:

• интерфейс моего сумматора как входов, так и выходов
• первый тривиальный тестовый пример (unit test бесплатно!)

то вы реализуете add().

Смотрите, это не имеет значения, если логику, обсуждаемую здесь, так просто реализовать. Чтобы иметь мышление TDD, нужно применять его все время без каких-либо исключений. Вы должны делать это так много раз, что больше не думаете об этом. Это просто часть того, как вы разрабатываете. Я могу сказать это, потому что видел, как это произошло со мной профессионально (это потребовало года упорства).

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

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

Человеческий ум, ИМО, легче работает с конкретными примерами (тестовыми сценариями/сценариями), а не абстрактным мышлением (как реализовать что-то). Имея тестовые примеры, он позволяет вашему уму постепенно узнать о проблеме, которую вы пытаетесь решить под рукой.

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

Ответ 4

"Итак, хотя кто-то действительно верит в TDD, вы на самом деле возвращаетесь назад старый стиль из-за времени давление/ проектные результаты".

Собственно, я не думаю, что это может быть правдой.

Если вы "возвращаетесь к старому стилю", единственная причина может заключаться в том, что вы не верите, что TDD быстрее создаст более качественный код.

Я думаю, что кто-то перестает использовать TDD, потому что они чувствуют, что он быстрее производит плохой код.

Ответ 5

Дисциплины.

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

Ответ 6

Попробуйте практиковать код ката.

Ката предназначена для запоминания. Студенты ката изучают его как форму, а не как вывод. Это не заключение ката, что имеет значение, это шаги, которые приводят к вывод. Если вы хотите опираться на подумайте, как я думаю, для разработки я проектирую, тогда вы должны научиться реагируйте на minutia так, как я реагирую. Следуя этой форме, вы сможете сделай это. Когда вы изучаете форму и повторите его и повторите, вы заставьте свой ум и тело ответьте, как я отвечаю на минутные факторы, которые приводят к разработке решения.

Код kata дал мне понять, что такое TDD должно чувствовать. Я знаю раньше, когда я начинаю терять ритм, чтобы вернуться к старым привычкам. В этот момент я знаю, что мне нужно делать небольшие шаги, чаще выполнять тесты, следить за тем, чтобы я не пытался реорганизовать под красным цветом и т.д.

Ответ 7

Купите "" Test Driven Development: By Example" от Kent Beck и прочитайте его.

Затем напишите неудачный unit test.

Ответ 8

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

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

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

Кроме того, важно, чтобы ваши тесты терпели неудачу. Письменные тесты, которые проходят, не помогут найти дефекты. И это еще одна очень хорошая причина для написания тестов в первую очередь - если вы сначала напишите код, а затем тесты, ваши тесты будут записаны для передачи кода и (непреднамеренно) смещены для проверки кода, а не желаемого результата. И как вы узнаете, что ваши тесты потерпят неудачу при отсутствии правильного кода? Поскольку тесты - это всего лишь код, они также подвержены ошибкам.

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

Ответ 9

Пара-программа, выполняющая TDD (в идеале с кем-то лучше вас),

Даже если это во время свободного времени

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

Найдите (или запустите) "Откат кода" или кодирование dojo с уделением особого внимания Программе сопряжения и TDD.

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

Ответ 10

Как вы, ребята, думаете, что я должен справиться с этим?

Я предлагаю вам подумать, что ваш модуль тестирует как диалоги с вашим объектом (при условии, что вы программируете с помощью языка с поддержкой OO, такого как Java, С#, Ruby, PHP и т.д.)

Создайте класс тестового примера, подумайте в своем тестовом методе о взаимодействии, которое вы хотите иметь с вашими объектами. Представьте, что вы разговариваете с интеллектуальной машиной, используя метод, который вы передаете своим объектам в виде глаголов, а затем используйте Asserts для проверки того, что объекты реагировали так, как вы хотите, чтобы они реагировали.

Через некоторое время вы можете наслаждаться таким стилем программирования настолько, что не ожидаете, что будете программировать без него; -)

Ответ 11

TDD - действительно хорошая практика (но в то же время я не думаю, что мы должны попытаться достичь 100% покрытия кода).

Основные преимущества:

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

• Вы думаете о том, как ваши методы должны работать. Это часто открывает некоторые неявные проблемы или недоразумения на ранних этапах.

• Когда у вас есть тесты, у вас есть хороший способ измерить процент выполненных работ (т.е. если у вас 20 тестов и 15 из них пройдены, то 75% работы завершено). Это более важно для вас как разработчика, чем для вашей команды или процесса. Вы просто делите всю задачу на многие более мелкие задачи (например, 20) и можете конкурировать с ними один за другим. Это гораздо приятнее, чем взять на себя все это.

• Тесты позволяют вам играть с кодом. Вы можете делать рефакторинг, вы можете повысить производительность и т.д. И снова, даже если вы этого не сделаете, это очень приятно понять, что у вас есть возможность сделать это. Это своего рода уверенность в том, что все в порядке.

Как заставить себя делать TDD? Вам не нужно! Если вы хотите получить все перечисленные преимущества, тогда вы не станете сами - вы просто будете делать TDD с удовольствием и своей свободной волей. Если вам не нужно/хотите/не получить их, не делайте этого сейчас.

Ответ 12

TDD заключается не столько в написании тестов в первую очередь. Если все, что вам нужно, это сначала написать свои тесты, тогда вам нужна методика Test-First. Проблема в том, что метод Test-First в вакууме (без TDD) заканчивается распадающимся на что-то, что почти хуже, чем отсутствие тестов вообще.

Вы сказали, что ваша проблема была самостоятельно:

или в ходе проекта TDD забывается в попытке быстрее завершить коды

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

Мое предложение состоит в том, чтобы потратить некоторое время на понимание ценности, которую оно может дать вам, признав виды артефактов, которые может заменить хороший тест. С истинным TDD один документ заполняет все следующие роли/потребности:

• Тест (работает ли это или нет?)
• Анализ (что мы пытаемся выполнить?)
• Дизайн (как мы это сделаем?)
• Спецификация (как мы узнаем, когда мы закончим?)
• Финишная линия (эй, все готово!)
• Отчет о проделанной работе (эй, они сделаны, еще?)
• Управление процессом (что мне делать дальше?)

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

Как только вы четко поняли это, вы можете начать беспокоиться о том, как делать TDD.

Ответ 13

Когда вы находитесь в большом беспорядке устаревшего кода, я нашел "Эффективно работать с устаревшим кодом" чрезвычайно полезен. Я думаю, что улучшите свою мотивацию для выделения TDD, даже если речь идет о написании модульных тестов, прежде чем вы внесете какие-либо изменения в свой старый код устаревшей версии. И из-за вашего вопроса, похоже, это та позиция, которой вы были.

И, конечно, как многие другие указали на дисциплину. Через некоторое время заставляя себя, вы забудете, почему вы когда-либо делали это по-другому.

Ответ 14

TDD - это знание того, что вы делаете, и что вы сделали. Если у меня есть правильная настройка TDD, я могу прокомментировать некоторую строку кода, которая, возможно, не нужна, а затем сразу же запустить тесты и выяснить, действительно ли это было необходимо при тестировании, - или нет, без тестирования. Эти тесты должны содержать достаточно описания, чтобы понять, зачем нужна эта строка кода.

Без TDD, определяющего, какие перерывы, когда вы меняете код, требует потенциально массивного регрессионного тестирования людей, прежде чем вы убедитесь, что у вас что-то не сломалось. Цель TDD, как и для всех частей Total Quality Management, - удалить большинство, если не все, необходимость дорогого ручного тестирования в конце линейки продуктов. Как? Зная, что вы делаете. Как? Измеряя, что вы делаете, и изучаете, как его улучшить.

Если вы обнаружите ошибку в своем коде и исправьте ее. Вопросы должны быть: как это произошло? Могу ли я предотвратить это в будущем? Как?

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

TDD является лишь частью этого и не будет работать без совместимой и обнадеживающей среды.

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

Об этом гораздо больше читать. Google следующие "Уильям Эдвард Деминг", "Управление полным качеством", "Кривая стоимости изменения".

Ответ 15

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

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

Для некоторых менеджеров может показаться, что TDD является дорогостоящим подходом, так как я полагаю, что может потребоваться немного больше времени, чтобы что-то закодировать (и это видят счетчики bean), но это краткосрочная "боль" для долгосрочный выигрыш. У вас есть (надеюсь) хорошо написанный, проверенный код, с механизмом, позволяющим собирать ошибки в будущем, когда что-то изменится.

Для всех, кто не убежден, дайте TDD на примере прочитанного и попробуйте повторить итерацию своего программного обеспечения.

Ответ 16

Многие практики кодирования принимают... практику.

• Через несколько часов вы сможете узнать и понять концепцию программирования OO. Но многие программисты признают, что только после практического программирования OO около 2 лет они внезапно почувствовали себя "бегло".

• Программист на С++ может легко "узнать С#" в течение нескольких дней. Но это все еще требует большой пользы, прежде чем они будут "свободно" и понимают все последствия всего, что они пишут (вместо того, чтобы быть программистом на С++, который преобразует синтаксис в С#).

• Я изначально научился вводить "два пальца". Это продвинулось до такой степени, что я мог довольно быстро набирать этот метод, но решил попробовать научиться touch-typing. В течение нескольких недель я заставлял себя испытывать боль и разочарование в том, что нужно набирать все очень медленно, используя сенсорный ввод. Это было тяжело и требовало реального обязательства, потому что с каждой строкой, которую я набрал, я просто хотел bash с тем, что я уже знал, способом, который дал бы мне быстрые результаты. Но в конечном итоге моя скорость набора текста совпала с моей двунаправленной печатью.

• Я сопротивлялся соглашениям префикса MFC (например, префиксы "m_" и "p" ), когда я впервые начал работать с MFC. Это казалось уродливым, смешным и бессмысленным дополнением. Затем я заставил себя использовать эту систему в течение месяца, и после этого времени я не мог понять, как я когда-либо писал код без этого соглашения об именах, - это помогло мне понять код лучше и быстрее и уменьшило количество глупых ошибок.

Итак, как вы развиваете дисциплину, чтобы делать TDD? Просто возьмите себя за TDD в течение месяца. Это будет медленно. Это будет сложно. Будет заманчиво просто bash вывести несколько строк "старый путь". Но через некоторое время вы будете наращивать опыт и скорость, и станет намного проще и естественнее работать таким образом. И тогда вы можете оценить TDD и не TDD и решить, какой подход работает лучше всего. Вы, вероятно, не оглядитесь назад.

Ответ 17

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

TDD (и Agile, если на то пошло) только начинает нажимать, когда вы и ваша команда все позади, и обязались заставить его работать. Вы должны получить выигрыш TDD под своим поясом, и это сделает вас верующим. Тогда вернитесь в свои другие проекты и будьте чемпионом. Начните где-нибудь, где вы можете получить эти решающие ранние победы. Все имеет значение.

Ответ 18

Ваша TDD-мантра для дня...

T в TDD - TODO или Task Driven

Я предпочитаю побуждать людей считать, что TDD - это постановка задач (например, тесты или спецификации). (Недопустимые задачи: Красный, Задачи завершены зеленым цветом.)

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

Конечно, в тот момент, когда вы начинаете рефакторинг и изменяете кодовую базу, вы получаете немедленную обратную связь и по ошибкам регрессии, и что вся часть выгоды.

Ответ 19

IMO, TDD с тестом/кодом/рефактором - звучит здорово и весело, но:

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

НТН.

РЕДАКТИРОВАТЬ: Чтобы уточнить мои пункты далее

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