Я не пишу тесты. Я тупой?

Ответ 1

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

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

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

Ответ 2

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

К моему удивлению, я быстро осознал достоинства тестирования. Функции, которые, как я думал, были на 100% идеальными, приведут к появлению странных результатов. Изменение одного компонента может привести к тому, что другой будет работать с unit test. Это было интересно, потому что я понял, что мой код работал только тогда, когда я вводил то, что я (как разработчик) ожидал от пользователя ввода, а не то, что они могли бы сделать в производственной версии приложения.

Этот сюрприз привел меня к ряду выводов о TDD (помимо типичных преимуществ):

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

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

Наконец, я знаю, что вы упомянули, что ваши проекты, как правило, небольшие, поэтому мой вопрос к вам - почему бы не проверить? Это не займет много времени, чтобы реализовать. Если вы работаете в .NET и Java, основная IDE имеет функции для оптимизации процесса тестирования. Я также готов поспорить, что другие языки имеют похожие функции в своих IDE.

Ответ 3

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

Ответ 4

По моему опыту, тесты - это документация. Если вам когда-нибудь придется объяснять, как что-то работает, вы указываете разработчиков на тесты. Комментарии, как правило, не так ценны, как тесты.

Ответ 5

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

Ответ 6

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

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

Ответ 7

Какие тесты вы проводите? Как часто вы проверяете, когда делаете изменения? Тестирует ли тестирование тестирования количество тестируемых тестов?

Для меня гораздо интереснее записывать повторяющиеся тесты, чем делать их вручную, снова и снова.

В целом, для меня, очевидно, важная вещь, чем один тест достаточно часто, чтобы поймать ошибки.

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

Большой трюк - решить, где сосредоточить усилия по тестированию. UI-х? Я проверяю это вручную. Gnarly вычислительных двигателей - пишите много тестовых примеров.

Ответ 8

Если никто не коснется кода снова, вам не нужно писать тесты для него, так как одним из преимуществ тестирования является ремонтопригодность (это правда? = P).

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

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

Ответ 9

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

EDIT:

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

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

Для всего остального автоматические тесты означают, что вы поставите более высокое качество с меньшей общей работой.

Ответ 13

Мой опыт:

• Написал 75 000 строк, критически важных приложений.
• С того дня, как мы подтолкнули эту программу к живому производству, она сделала то, что означало с надежной надежностью на породе.

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

Форма тестирования, которая работала для меня:

• Я не делал то, что рекомендовали некоторые практикующие, а именно "тест сначала, а затем код". Скорее, я принял подход к интеграции как можно большего количества тестов в проект, как я мог думать, до или после фактического кода. Для некоторых методов было проще сначала написать метод, затем тесты. Для других методов легче было сначала написать тесты, затем метод.
• Я не использовал рамки модульного тестирования, а я интегрировал тесты в саму программу, как описано в остальных пунктах. Единственной базой, которую я использовал, была сторонняя структура ведения журнала для любых генерируемых предупреждений и ошибок. Я не буду называть коммерческий, который я использовал, чтобы сохранить эту статью нейтральной, и любая свободная или коммерческая структура ведения журнала будет делать. Я рекомендую любую структуру ведения журнала, которая позволяет вам просматривать журнал, а затем фильтровать по некоторым критериям, так как это очень полезно при просмотре больших журналов для любой подозрительной деятельности.
• Использовано тестирование уровня класса: у каждого класса был метод, который проверял все другие методы в классе. У некоторых методов был метод "сестра", который отвечал за выполнение тестов по указанному методу.
• Использовано тестирование уровня приложения: написано много модульных тестов для подкачки реальных данных в программу, а затем проверьте, чтобы возвращаемые данные были такими, как ожидалось (обычно это было просто проверка границ).
• Использовано линейное тестирование: каждый раз, когда я знал ожидаемый диапазон значений внутри переменной или массива, я записывал бы молчащее предупреждение, если данные падали вне этого диапазона. Другими словами, у меня было модульное тестирование, интегрированное в саму структуру кода. Эти тесты можно было отключить в режиме Release, но я обнаружил, что он не сильно повлиял на скорость конечного приложения, поэтому я просто оставил их.

Из всего теста, который я добавил, я обнаружил, что линейное тестирование уровня оказало наибольшее положительное влияние на надежность приложения в целом. Удивительно, как простое правило, такое как "log the silent warning message, если содержимое переменной не то, что вы ожидаете", может оказать такое глубокое влияние на надежность приложения в целом.

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

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

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

Ответ 14

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

Ответ 15

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

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

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

Ответ 16

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

Ответ 17

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

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

Ответ 18

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

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

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

Ответ 19

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

Ответ 20

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

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

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

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