Вы действительно используете модульные тесты? [закрытый]

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

50
задан Ken 18 November 2008 в 13:11
поделиться

18 ответов

Используя поблочное тестирование навык кодирования.

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

А полное обсуждение преимуществ здесь: действительно ли Поблочное тестирование стоит усилия?

71
ответ дан Community 7 November 2019 в 20:28
поделиться

Другое очень полезное напоминание того, почему Вы хотите к модульному тесту везде, где Вы можете просто, обнаружилось в этом сообщении: Лучшие 12 Причин Записать Модульные тесты мне нужно было выгравировать это на моих сетчатках.

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

1
ответ дан orcmid 7 November 2019 в 20:28
поделиться

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

1
ответ дан Ryan Thames 7 November 2019 в 20:28
поделиться

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

1
ответ дан casademora 7 November 2019 в 20:28
поделиться

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

Так да, я использую его!

1
ответ дан e-satis 7 November 2019 в 20:28
поделиться

Большинство функций, которые я пишу, имеет тесты. Как многие сказали там, поблочное тестирование является основной частью разработки программного обеспечения. Так, для ответа на вопрос, да, я ДЕЙСТВИТЕЛЬНО пишу и запускаю тесты.

кроме того, с непрерывная интеграция , регрессионные тесты автоматизируют и постоянно сообщать.

1
ответ дан yclian 7 November 2019 в 20:28
поделиться

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

3
ответ дан schnaader 7 November 2019 в 20:28
поделиться

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

7
ответ дан David Sykes 7 November 2019 в 20:28
поделиться

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

12
ответ дан annakata 7 November 2019 в 20:28
поделиться

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

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

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

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

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

7
ответ дан David Hall 7 November 2019 в 20:28
поделиться

Я - большой поклонник поблочного тестирования, главным образом потому что это полностью addicitive - "code-test-see, ужасная красная bar-fix-test-see прекрасная зеленая панель" цикл в JUnit серьезно получает нагнетание эндорфинов.

4
ответ дан nayfnu 7 November 2019 в 20:28
поделиться

Моя компания делает компоненты системы для различных компаний в Авиакосмической промышленности. ФАА требует Измененного Покрытия Условия/Решения для Уровня качества Безопасность Критическое программное обеспечение полета ( DO-178-B) Так для проверки, которую мы делаем (снова от DO-178-B):

Анализ всего кода и трассируемости от тестов и результатов ко всем требованиям обычно требуется (в зависимости от программного уровня).

Этот процесс обычно также включает:

основанные на требованиях инструменты тестирования

инструменты анализатора покрытия Кода

Другие названия тестов, выполненных в этом процессе, могут быть:

<блок цитирования>

Поблочное тестирование

Интеграционное тестирование

Тестирование методом "черного ящика" и приемочные испытания

Поблочное тестирование показывает ошибки в коде все время.

2
ответ дан Paul 7 November 2019 в 20:28
поделиться

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

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

7
ответ дан JesperE 7 November 2019 в 20:28
поделиться

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

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

2
ответ дан xando 7 November 2019 в 20:28
поделиться

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

1
ответ дан Codebeef 7 November 2019 в 20:28
поделиться

Я соглашаюсь с Ken, что поблочное тестирование является частью разработки программного обеспечения.

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

Другое преимущество - то, что Вы знаете, где Вы, поскольку код, который был записан, был уже протестирован на единицу.

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

4
ответ дан philant 7 November 2019 в 20:28
поделиться

Я буду честен. Я только недавно начал писать модульные тесты, и когда я возвращаюсь для изменения старого DLL, это с моих плохих былых времен, я буду сидеть на корточках и писать модульные тесты для получения его около 100%-го покрытия кода. Я говорю "рядом", потому что последний несколько процентов может быть трудно получить до должного к способу, которым код структурирован, что это не имело насмешки или поблочного тестирования в виду (это происходит много с абстрактными классами или классами что P/Invoke в собственный код). И в то время как я понимаю, что 100%-е покрытие кода не является тем же самым, поскольку 100% всего выполнения кода соединяют каналом, я нашел, что наличие тестов существует хороший способ сказать, когда я делаю что-то, что это собирается повредить много вещей.

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

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

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

  • 1118-секундный, никому не нравится говорить о том, что классический цикл управляемой отладки кода на самом деле работает "достаточно хороший", когда Вы

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

  • Четвертое, поблочное тестирование является довольно недавними инновациями. (О, тишина... Я знаю, что идея была вокруг навсегда, особенно в для решения ответственных задач и приложениях DoD, но для "Joe Водопроводчик Разработчик" типы как я? Поблочное тестирование не было упомянуто вообще во время моей всей карьеры студента CS в начале этого десятилетия; в 2008 я слышу, что это - требование для всех проектов от уровня 101. Visual Studio даже не получала встроенную среду тестирования до этого года, и даже тогда только в профессиональном выпуске.) Был он блаженное неведение с моей стороны? Несомненно, и я думаю много людей, которые кодируют, потому что это - их дневное задание (который прекрасен), просто не знают. Если они, то они знают, что должны остаться текущими, но когда дело доходит до изучения новой методологии (особенно та, которая включает запись большего количества кода и взятие более первичного времени, когда Вам была нужна та новая возможность, сделанная вчера ) означает, что это будет пододвинуто обратно. Это - длинный хвост, и приблизительно через одно десятилетие наши переговоры о поблочном тестировании будут казаться столь же странными как наше бормотание об объектно-ориентированном программировании, разрешающем новую эру разработки в течение 1990-х. Heck, если я имею , запустил поблочное тестирование, конец должен быть рядом, потому что я обычно - идиот.

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

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

Так, извинения за хаотичное сообщение. Таким образом:

  • я не делал модульного теста в течение долгого времени. Теперь я делаю. Модульные тесты являются большим инструментом, особенно во время обслуживания.

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

Позволяют провокационным сообщениям начаться! =)

37
ответ дан Nicholas Piasecki 7 November 2019 в 20:28
поделиться

Мне нравится аналогия Bob Martin: предположите, что Вы - хирург. Что Вы сказали бы пациенту, который хотел заплатить хирургию, но сказал Вам пропускать мыть руки загодя?

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

8
ответ дан Jeffrey Fredrick 7 November 2019 в 20:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: