Каковы некоторые причины, почему единственный разработчик должен использовать TDD? [закрытый]
Я помещаю превосходный ответ JLBorges на аналогичный вопрос дословно из cplusplus.com, так как это наиболее краткое объяснение, которое я прочитал по этому вопросу.
] В шаблоне, который мы пишем, есть два типа имен, которые можно использовать - зависимые имена и не зависимые имена. Зависимое имя - это имя, которое зависит от параметра шаблона; неизменяемое имя имеет то же значение, независимо от параметров шаблона.
Например:
template< typename T > void foo( T& x, std::string str, int count ) { // these names are looked up during the second phase // when foo is instantiated and the type T is known x.size(); // dependant name (non-type) T::instance_count ; // dependant name (non-type) typename T::iterator i ; // dependant name (type) // during the first phase, // T::instance_count is treated as a non-type (this is the default) // the typename keyword specifies that T::iterator is to be treated as a type. // these names are looked up during the first phase std::string::size_type s ; // non-dependant name (type) std::string::npos ; // non-dependant name (non-type) str.empty() ; // non-dependant name (non-type) count ; // non-dependant name (non-type) }То, что зависит от зависимого имени, может быть чем-то другим для каждого конкретного экземпляра шаблона. Как следствие, шаблоны C ++ подвержены «двухфазному поиску имен». Когда шаблон сначала анализируется (до того, как выполняется какое-либо создание), компилятор просматривает не зависящие имена. Когда происходит конкретное создание шаблона, параметры шаблона известны к тому времени, и компилятор ищет зависимые имена.
На первом этапе анализатор должен знать, является ли зависимое имя именем типа или имени не-типа. По умолчанию зависимым именем считается имя не-типа.
Использовать ключевое слово typename только в объявлениях шаблонов и определениях, приведенных ниже.
blockquote>у вас есть квалифицированное имя, которое относится к типу и зависит от параметра шаблона.
20 ответов
я не собираюсь слепо следовать чему-либо.
Это - правильное отношение. Я использую TDD все время, но я не придерживаюсь его так же строго как некоторые.
лучший аргумент (в моем уме) в пользу TDD - то, что Вы получаете ряд тестов, которые можно запустить, когда Вы наконец добираетесь до рефакторинга и этапы технического обслуживания Вашего проекта. Если это - Ваша единственная причина использования TDD, то можно записать тестам любое время, которое Вы хотите, вместо того, чтобы слепо следовать методологии.
другая причина я использую TDD, то, что запись тестов получает меня думающий о моем API впереди. Я вынужден думать о том, как я собираюсь использовать класс, прежде чем я запишу его. Получение моей головы в проект на этом высоком уровне работает на меня. Существуют другие способы сделать это, и если бы Вы нашли другие методы (существуют много) сделать то же самое, тогда я сказал бы, продолжают делать что работы для Вас.
Я думаю TDD, поскольку методология примерно "не имеет тестов при внесении изменений", таким образом это не зависит от команды - ни от размера проекта. Это о замечании ожиданий о том, что делает пайса приложения кода/, ПРЕЖДЕ ЧЕМ каждый начинает действительно думать о том, КАК отмеченное поведение реализовано. Основной фокус TDD не только имеет в распоряжении тест для записанного кода, но пишет меньше кода, потому что Вы просто делаете то, что делает тест зеленым (и осуществите рефакторинг позже).
, Если Вы похожи на меня и вполне трудно думать о том, что часть / целое приложение ОБХОДИТСЯ БЕЗ размышления о том, как реализовать его, я думаю, что его штраф пишет Ваш тест после Вашего кода и таким образом разрешения коду "управлять" тестами.
, Если Ваш вопрос не так о тесте, первом (TDD) или тест - после (хорошее кодирование?) Я думаю, тестируя, должна быть стандартная практика для любого разработчика, или один или в многочисленной команде, которая создает код, который остается в производстве дольше, чем три месяца. В моем опыте это - промежуток, после которого даже исходный автор должен думать трудно о том, что делают эти двадцать строк комплекса, супероптимизированного, но редко зарегистрированный код действительно кодируют. Если у Вас есть тесты (которые покрывают все пути throughth код), там меньше, чтобы думать - и меньше ДОПУСТИТЬ ОШИБКУ о, даже несколько лет спустя...
Вот несколько мемов и мои ответы:
"TDD заставил меня думать о том, как он перестал бы работать, который сделал меня, лучший программист"
, Учитывая достаточный опыт, высоко касавшийся видов отказа, должен естественно стать частью Вашего процесса так или иначе.
"Приложения должны работать правильно",
Это предполагает, что Вы в состоянии протестировать абсолютно все. Вы не собираетесь быть немного лучше при покрытии всех возможных тестов правильно, чем Вы были при записи функционального кода правильно во-первых. "Приложения должны работать лучше ", намного лучший аргумент. Я соглашаюсь с этим, но это идеалистически и достаточно не совсем материально для мотивации столько, сколько мне жаль, что это не было бы. Метрики/истории были бы большими здесь.
"Работавший отлично для моего < компонент библиотеки X>";
я сказал в вопросе, что видел значение в этих случаях, но спасибо за историю.
"Думают о следующем разработчике",
Это - вероятно, один из лучших аргументов мне. Однако довольно вероятно, что следующий разработчик не практиковал бы TDD или, и это поэтому будут отходы или возможно даже нагрузка в этом случае. Закулисный евангелизм - то, что он составляет там. Я совершенно уверен, что разработчик TDD был бы действительно appeciate он, все же.
то, Насколько Вы собираетесь ценить проекты, в которых выполняют удержанный от использования, должно - делать методологии, когда Вы наследовали тот? RUP, кто-либо? Думайте о том, что TDD значит для следующего разработчика, если TDD не является столь большим, как все думают, что это.
"Рефакторинг намного легче"
, Рефакторинг является навыком как любой другой, и итерационная разработка, конечно, требует этого навыка. Я склонен выбрасывать значительные объемы кода, если бы я думаю, что новый дизайн сэкономит время в конечном счете, и такое чувство, что было бы ужасное количество тестов, выброшенных также. Который более эффективен? Я не знаю.
...
я, вероятно, рекомендовал бы некоторый уровень TDD любому новому..., но я все еще испытываю затруднения из-за преимуществ для любого, кто несколько раз уже был вокруг блока. Я, вероятно, начну добавлять автоматизированные тесты к библиотекам. Возможно, что после выполнения этого, я буду видеть больше значения в выполнении его обычно.
Единственный разработчик должен использовать TDD на своем проекте (послужной список не имеет значения), так как в конечном счете этот проект мог быть передан некоторому другому разработчику. Или больше разработчиков могло быть введено.
Новые люди будут иметь, чрезвычайно имеют трудное время, работая с кодом без тестов. Они повредят вещи.
Ваш клиент владеет исходным кодом, когда Вы поставляете продукт? Если можно убедить их, что поставка продукта с модульными тестами увеличивает стоимость, то Вы увеличиваете стоимость покупки своих сервисов и поставляете лучший продукт. С точки зрения клиента тестовое покрытие не только гарантирует качество, это позволяет будущим специалистам по обслуживанию понимать код намного с большей готовностью начиная с тестов изолированная функциональность от UI.
Я чувствую, что как сольный разработчик на проекте, особенно больший, Вы склонны быть распространенными довольно худые.
Вы посреди большого рефакторинга, когда внезапно несколько критических ошибок обнаруживаются, который по некоторым причинам не обнаружился во время предрелизного тестирования. В этом случае необходимо отбросить все и зафиксировать их, и потратив две недели, разрывая волосы можно наконец возвратиться к тому, что Вы делали прежде.
А неделю спустя один из Ваших крупнейших клиентов понимает, что у них абсолютно должна быть эта прохладная новая солнечная функция, или иначе они не разместят заказ для тех 1M единицы, которые они должны были уже заказать месяц назад.
Теперь, три месяца спустя Вы даже не помните, почему Вы начали осуществлять рефакторинг во-первых уже не говоря о том, что код, который Вы осуществляете рефакторинг, как предполагалось, сделал. Слава Богу Вы делали хорошие записи задания те модульные тесты, потому что, по крайней мере, они говорят Вам, что Ваш пересмотренный код все еще делает то, что он, как предполагалось, сделал.
Пена, промывка, повторение.
.. история моей жизни в течение прошлых 6 месяцев.:-/
Я собираюсь ответить на этот вопрос вполне быстро, и надо надеяться Вы начнете видеть часть обоснования, даже если Вы все еще не согласитесь.:)
, Если Вам повезло быть на продолжительном проекте, тогда будут времена, когда Вы захотите, например, запишите, что Ваши данные разделяют на уровни сначала, тогда возможно, бизнес-уровень, перед углублением стека. Если Ваш клиент тогда вносит изменение требования, которое требует, переделывают на Вашем слое данных, ряд модульных тестов на слое данных гарантирует, чтобы Ваши методы не перестали работать нежелательными способами (предполагающий обновление тестов для отражения новых требований). Однако Вы, вероятно, будете называть метод слоя данных от бизнес-слоя также, и возможно в нескольких местах.
Позволяют нам предположить, что у Вас есть 3 вызова к методу в бизнес-слое, но Вы только изменяете 2. В третьем методе можно все еще возвращать данные из слоя данных, который, кажется, допустим, но может повредить некоторые предположения, которые Вы кодировали за месяцы до этого. Модульные тесты на этом уровне (и выше) должны были быть разработаны для определения поврежденных предположений, и в сбое они должны выделиться Вам, что существует раздел кода, который должен быть пересмотрен.
я надеюсь, что этого очень упрощенного примера будет достаточно для получения Вас думающий о TDD немного больше, и что это могло бы создать искру, которая заставляет Вас рассмотреть использование его. Конечно, если Вы все еще не видите точку, и Вы уверены в своих собственных способностях отслеживать много тысяч строк кода, тогда у меня нет места, чтобы сказать Вам, что необходимо запустить TDD.
Точка о записи тестов сначала - то, что она осуществляет требования и проектные решения, которые Вы делаете. Когда я модификация код, я хочу удостовериться, что те все еще осуществляются, и достаточно легко "повредить" что-то, не получая компилятор или ошибку времени выполнения.
у меня есть тест, сначала приближаются, потому что я хочу иметь высокую степень уверенности в моем коде. Предоставленный, тесты должны быть хорошими тестами, или они ничего не осуществляют.
у меня есть некоторые довольно большие кодовые базы, что я продолжаю работать и существует большое нетривиальное продолжение материала. Достаточно легко внести изменения, которые слегка колеблются, и внезапно X происходит, когда X никогда не должен происходить. Мои тесты несколько раз сохраняли меня от создания критического (но тонкий) ошибка, которая, возможно, осталась незамеченной тестерами - людьми.
, Когда тесты действительно перестали работать, они - возможности посмотреть на них, и производство кодируют и удостоверяются, что это корректно. Иногда конструктивные изменения и тесты должны будут быть изменены. Иногда я буду писать что-то, что передает 99 из 100 тестов. То, что 1 тест, который не передал, похож на коллегу, рассматривающего мой код (в некотором смысле), чтобы удостовериться, что я все еще создаю то, что я, как предполагается, создаю.
TDD позволяет мне более ясно определить проблему в голове. Это помогает мне сфокусироваться на реализации просто функциональности, которая требуется, и ничто больше. Это также помогает мне создать лучший API, потому что я пишу "клиенту", прежде чем я запишу сам код. Я могу также осуществить рефакторинг, не имея необходимость волноваться о повреждении чего-либо.
Я склонен соглашаться с законностью Вашей точки об издержках TDD для 'одного разработчика' или проектов 'хобби', не выравнивающих по ширине расходы.
необходимо полагать однако, что большинство лучших практик релевантно и полезно, если они последовательно применяются в течение длительного периода времени.
, Например, TDD сохраняет Вас testing/bugfixing время в длительный период, не в течение 5 минут после создания первого модульного теста.
Вы - программист контракта, что означает, что Вы оставите свой текущий проект, когда он будет закончен и переключится на что-то еще, скорее всего, в другой компании. Ваш текущий клиент должен будет поддержать и поддержать Ваше приложение. Если Вы не оставите службу поддержки хорошей платформой для работы с, то они застрянут. TDD поможет проекту быть устойчивым. Это увеличит устойчивость кодовой базы, таким образом, другие люди с меньшим опытом не будут в состоянии не, действительно очень повреждают попытку изменить его.
То же касается проектов хобби. Вы можете устать от него и захотите передать его кому-то. Вы могли бы стать коммерчески успешными (думайте Craiglist), и будет иметь еще 5 людей, работающих помимо Вас.
Инвестиции в надлежащий процесс всегда выплаты, даже если это просто приобретено опыт. Но большую часть времени Вы будете благодарны, что при запуске нового проекта Вы решили сделать это правильно
, необходимо рассмотреть ДРУГОЙ люди при выполнении чего-то. Вы необходимо предположить, план относительно [1 113] рост , план относительно [1 114] устойчивость .
, Если Вы не хотите делать, это - придерживается ковбоя, кодирующего, это намного более просто этот путь.
P.S. То же самое относится к другим методам:
- , Если Вы не комментируете свой код и у Вас есть идеальная память, Вы будете в порядке, но кто-то еще читающий Ваш код не будет.
- , Если Вы не документируете свои обсуждения с клиентом, кто-то еще ничего не будет знать о важнейшем решении, которое Вы приняли
и т.д. до бесконечности
TDD не о тестировании, которое это о записи кода. По сути, это предоставляет много преимуществ для даже единственного разработчика. Для многих разработчиков это - mindshift для записи большего количества устойчивого кода. Например, как часто Вы думаете "Теперь, как это может кодировать сбой?" после писания кода без TDD? Для многих разработчиков ответ на тот вопрос не ни один. Для специалистов TDD это смещает мышление к к выполнению вещей как проверка, если объекты или строки являются пустыми прежде, чем сделать что-то с ними, потому что Вы пишете, тесты, чтобы конкретно сделать это (повредите код).
Другая основная причина является изменением. Каждый раз, когда Вы имеете дело с клиентом, они, никогда может казаться, не решаются. Единственная константа является изменением. TDD помогает как "система поддержки" найти все другие области, которые могли повредиться. Даже на маленьких проектах это может помешать Вам зажигать драгоценное время в отладчике.
я мог пойти и на, но я думаю, говоря, что TDD больше о записи кода, чем чего-нибудь должно быть достаточно для выравнивания по ширине, это - использование в качестве единственного разработчика.
Тесты позволяют Вам осуществлять рефакторинг с уверенностью, что Вы не повреждаете систему. Запись тестов сначала позволяет тестам определять то, что работает поведение на систему. Любое поведение, которое не определяется тестом, является по определению побочным продуктом и позволенный измениться при рефакторинге. Запись тестов сначала также управляет дизайном в хороших направлениях. Для поддержки тестируемости, Вы находите, что необходимо разъединить классы, используйте интерфейсы и следуйте за хорошим шаблоном (Инверсия Управления, например) для создания кода легко тестируемым. Если Вы тесты записи впоследствии, Вы не можете быть уверены, что покрыли все поведение, ожидаемое Вашей системы в тестах. Вы также находите, что некоторые вещи трудно протестировать из-за дизайна - так как он был, вероятно, разработан, не тестируя в памяти - и испытывает желание сэкономить или опустить тесты.
я обычно работаю соло и главным образом делаю TDD - случаи, где я не делаю просто, где я не удаюсь соответствовать своим методам или еще не нашел хороший путь, который работает на меня, чтобы сделать TDD, например, с веб-интерфейсами.
У меня нет огромной суммы опыта, но у меня был опыт наблюдения резко контрастировавших подходов к тестированию.
В одном задании, не было никакого автоматизированного тестирования. "Тестирование" состояло из ввода по абсолютному адресу вокруг в приложении, пробуя любой вытолканный в Вашей голове, чтобы видеть, повредилось ли это. Само собой разумеется, для кода flat-out-broken было легко достигнуть нашего рабочего сервера.
В моем текущем задании, существует большое автоматизированное тестирование и полная система CI. Теперь, когда код повреждается, это сразу очевидно. Не только, что, но и поскольку я работаю, тесты действительно документ, какие функции работают в моем коде, и что еще не имеет. Это вселяет в меня большую веру, чтобы быть в состоянии добавить новые опции, зная, что, если я повреждаю существующие, это не останется незамеченным.
Так, мне, это зависит не так от размера команды, но размера приложения. Можно ли отслеживать каждую часть приложения? Каждое требование? Каждый тест, который необходимо запустить для проверки приложения, работает? Что это даже означает говорить, что приложение "работает", если у Вас нет тестов для доказательства его?
Просто мои 0,02$.
Не имеет значения, являетесь ли Вы единственным разработчиком или нет. Необходимо думать о нем с точки зрения приложения. Все приложения должны работать правильно, все приложения должны сохраняться, все приложения должно быть меньше багги. Существуют, конечно, определенные сценарии, где подход TDD не мог бы подойти Вам. Это - когда крайний срок приближается очень быстро и никакое время для выполнения поблочного тестирования.
Так или иначе, TDD не зависит от соло или среды команды. Это зависит от приложения в целом.
Я - также программист контракта. Вот мои 12 Причин Почему я Любовные Модульные тесты .
Мой лучший опыт с TDD центрируется вокруг проект pyftpdlib. Большая часть разработки сделана исходным автором, и я сделал несколько маленьких вкладов, но это - по существу сольный проект. Набор тестов для проекта очень полон, и тестирует все основные функции библиотеки FTPd. Перед регистрацией в изменениях или выпуском версии, все тесты проверяются, и когда новая опция добавляется, набор тестов всегда обновляется также.
В результате этого подхода, это - единственный проект, я когда-либо работал над этим, не имел showstopper ошибок, появляются после нового выпуска, имеют изменения, зарегистрировался, который повредил основную функцию и т.д. Код очень тверд, и я последовательно впечатлялся тем, как немного отчетов об ошибках были открыты во время срока действия проекта. Я (и исходный автор) приписываю большую часть этого успеха к комплекту комплексного испытания и способности протестировать каждый главный путь выполнения кода по желанию.
С логической точки зрения, любой код, который Вы пишете, должен быть протестирован, и без TDD тогда Вы будете тестировать его сами вручную. На обороте к pyftpdlib, худшему коду количеством ошибок и частотой главных проблем, код, который только тестируется разработчиками и QA, испытывающим новые возможности вручную. Вещи не становятся протестированными из-за уплотнения времени или проваливающийся трещины. О старых путях выполнения кода забывают, и даже самые старые стабильные функции заканчивают тем, что повредились, главные версии заканчиваются с важными нефункциональными функциями. и т.д. Ручное тестирование критически важно для проверки и некоторой рандомизации тестирования, но на основе моих событий я сказал бы, что важно иметь и ручное тестирование и тщательно созданную платформу модульного теста. Между двумя подходами разрывы в покрытии меньше, и Ваша вероятность проблем может только быть уменьшена.
Хорошо моя очередь... Я сделал бы TDD даже самостоятельно (для кода non-spike/experimental/prototype), потому что
- Думают перед прыганием : вынуждает меня думать, что я хочу быть сделанным, прежде чем я начну проворачивать код. Что я пытаюсь выполнить здесь.. 'Если я предполагаю, что у меня уже была эта часть.. как я ожидал бы, что он будет работать?' Интерфейс Encourages - в дизайне объектов.
- Легче измениться : Я могу сделать модификации с уверенностью.. 'Я ничего не повредил в step1-10, когда я изменил step5'. Регрессионное тестирование мгновенно
- , Лучшие проекты появляются : я нашел лучшие проекты, появляющиеся без меня инвестирующий усилие в действие дизайна. протестируйте сначала + Осуществляющий рефакторинг вывод к слабо связанным, минимальным классам с минимальными методами.. никакая сверхразработка.. никакой код YAGNI. Классы имеют лучшие открытые интерфейсы, маленькие методы и более читаемы. Это - своего рода вещь дзэн.. Вы только замечаете, что получили его, когда Вы 'получаете его'.
- отладчик больше не является моей опорой : Я знаю то, что делает моя программа.. не имея необходимость проводить часы, ступая через мой собственный код. В наше время, Если я провожу больше чем 10 минут с отладчиком.. умственные предупреждения начинают звонить.
- Помогает мне пойти домой вовремя , я заметил отмеченное уменьшение в количестве ошибок в моем коде начиная с TDD.. даже если утверждение похоже на Консольную трассировку и не тип xUnit В.
- Производительность / Поток : это помогает мне определить следующий дискретный маленький шаг, который возьмет меня к сделанному... сохраняет прокрутку снежка. TDD помогает мне войти в ритм (или что поток вызовов XPers) более быстрый. Я получаю больший блок качественной работы, сделанной в единицу времени, чем прежде. red-green-refactor цикл превращается... в своего рода вечный двигатель.
- я могу доказать, что мой код работает при нажатии кнопки
- , Практика делает прекрасным , я учусь & определение драконов быстрее.. с большим количеством времени TDD под моим поясом. Возможно, разногласие.. но я чувствую, что TDD сделал меня лучшим программистом, даже когда я не иду тест сначала. Определение возможностей рефакторинга стало второй натурой...
я обновлю, если я буду больше думать.. это - то, что я придумал в прошлые 2 минуты отражения.
Я нахожу его еще более полезным когда летающее соло. Ни с кем вокруг для возврата идей прочь и никто вокруг для выполнения экспертных оценок Вам будет нужно некоторое обеспечение, что Вы - код, твердо. TDD/BDD предоставит то обеспечение Вам. TDD является небольшим contraversial, все же. Другие могут полностью не согласиться с тем, что я говорю.
РЕДАКТИРОВАНИЕ: я мог бы добавить, что при правильной организации, можно на самом деле генерировать спецификации для программного обеспечения одновременно Вы тесты записи. Это - большой побочный эффект BDD. Можно заставить себя быть похожими на супер разработчика при провороте твердого кода наряду со спецификациями, все самостоятельно.
Я больше ничего не осуществляю рефакторинг без разумного набора модульных тестов.
я не делаю настоящего TDD с модульными тестами сначала и вторым кодом. Я делаю CALTAL - Код Немного, Тест Немного - разработка. Обычно код идет сначала, но не всегда.
, Когда я нахожу, что должен осуществить рефакторинг, я удостоверяюсь, что у меня есть достаточно тестов, и затем я взламываю далеко в структуре с полной уверенностью, что я не должен сохранять весь план old-architecture-becomes-new-architecture в голове. Я просто должен заставить тесты передавать снова.
я осуществляю рефакторинг важные биты. Заставьте существующий комплект тестов передавать.
Тогда я понимаю, что забыл что-то, и я вернулся к разработке CALTAL на новом материале.
Тогда я вижу вещи, которые я забыл удалять - но являюсь ими действительно неиспользованный везде? Удалите их и посмотрите что сбои в тестировании.
Только вчера - часть путь посредством большого рефакторинга - я понял, что у меня все еще не было точного правильного дизайна. Но тесты все еще должны были передать, таким образом, я был свободен осуществить рефакторинг свой рефакторинг, прежде чем я был даже сделан с первым рефакторингом. (гмм!) И все это работало приятно, потому что у меня был ряд тестов для проверки изменений против.
Для летающего сольного TDD мой второй пилот.
Личный интерес.
В моем случае, единственный разработчик переводится как владелец малого бизнеса. Я написал достаточное количество библиотечного кода, чтобы (якобы) облегчить себе жизнь. Многие из этих подпрограмм и классов не относятся к ракетостроению, поэтому я могу быть уверен, что они работают правильно (по крайней мере, в большинстве случаев), просмотрев код, проведя некоторое выборочное тестирование и отладив методы, чтобы убедиться, что они ведут себя соответствующим образом. Я думаю, что да. Грубая сила, если хотите. Жизнь прекрасна.
Со временем эта библиотека разрастается и используется в большем количестве проектов для разных клиентов. На тестирование уходит больше времени. Особенно в тех случаях, когда я (надеюсь) исправляю ошибки и (еще более надеюсь) не ломаю что-то еще. И это не только из-за ошибок в моем коде. Я должен быть осторожен, добавляя функциональные возможности (клиенты все время просят «еще кое-что») или удостоверяюсь, что код по-прежнему работает при переходе на новую версию моего компилятора (Delphi!), Сторонний код, среду выполнения или операционную систему.
В крайнем случае, я мог потратить больше времени на просмотр старого кода, чем на работу над новыми (читай: оплачиваемыми) проектами. Думайте об этом как об угле покоя программного обеспечения (насколько высоко вы можете сложить непроверенное программное обеспечение, прежде чем оно упадет :).
Такие методы, как TDD, дают мне методы и классы, которые более продуманы, более тщательно протестированы (прежде чем клиент получит их) и требуют меньше обслуживания в будущем.
В конечном итоге, это означает, что меньше времени уделяется обслуживанию и больше времени тратится на более прибыльные, более интересные (почти все) и более важные (например, семья).