Тип Проектов, где Поблочное тестирование бесполезно [закрытый]

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

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

Если я хочу протестировать эту функциональность, я должен создать средство моделирования, которое моделирует поведение машины для выполнения некоторых функциональных тестирований на этом классе. Создание средства моделирования, вероятно, взяло бы по крайней мере 50% времени, в котором я требовался для коммуникатора.

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

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

Я редко нахожу поблочное тестирование (на уровне класса) любого значения. Я могу легко сделать такое тестирование путем обхода через отладчик, когда я разрабатываю код. Я предпочитаю тестировать классы, которые, как предполагается, сотрудничают как единица. Я получаю путь больше удара для маркера, проявляющего этот подход. В конце концов, я действительно не забочусь, делает ли functionX точно, что я думаю, что он, как предполагается, делает, когда это отдельно, но не делает то, что он ДОЛЖЕН сделать при работе с другими классами в системе.

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

Если Вы пишете полезные модульные тесты, то Ваше задание является, вероятно, не чем-то обычным :)

Править: Наоборот, интеграционные тесты обычно очень полезны, но намного более трудны автоматизировать затем модульные тесты.

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

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

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

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

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

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

Кажется, что Вы тестируете неправильную вещь.

Почему гасят вызовы базы данных? Для почему бы не создания тестовой базы данных и теста, фактическая база данных звонит против той тестовой базы данных? [Это - путь Django testserver работы, и это является большим.]

Почему насмешка бизнес-объекты? Это - то, что Вы тестируете, правильно? Это должно хорошо сказать, что "мы принимаем работы ORM" и объявляем, что Ваша "единица" является бизнес-объектом + база данных ORM +. Тест, что, так как это - то, где вопросы возникают.

Модульный тест вещи Вы записали.

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

Модульные тесты могут существовать слоев - можно записать подобные интеграции тесты, которые предполагают, что уровень ORM уже прошел все свои тесты.

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

Я хотел бы в кого-то доказать меня неправильно об этом, все же.

Перефразировать недавние комментарии Jeff & Joel к РЫДАНИЮ: необходимо сделать поблочное тестирование, когда оно увеличивает стоимость продукта.

В этих двух случаях Вы описываете, Вы смогли бы сделать МНОГО специальных мер (и/или post-facto регрессионное тестирование) для той же стоимости как запись модульных тестов. Не пишите модульные тесты.

Для ответа на вопрос существуют определенно некоторые исключения.

На самом деле я сказал бы, что полноценность автоматизированного тестирования методом "белого ящика" более вероятна исключение, а не правило.

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

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

Лучше, чтобы понять это и использовать его, где это могло быть полезно. Например, мой друг был SDET в команде Microsoft Frarmework - это было большим примером того, где TDD был большим активом. Таким образом, они разрабатывали механизм для среды разработки, которая будет использоваться миллионами людей.

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

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

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

В Вашем первом примере я был бы модульный тест преобразование PDF следующим образом:

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

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

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

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

В Вашем втором примере это кажется на тестирование стороннего инструмента ORM который, вероятно, бессмыслен. Однако снова некоторые базовые тесты могут быть полезными как страховка от будущих изменений повреждения, в зависимости от того, как Вы используете инструмент. Например, вместо того, чтобы копировать всю n-tier цепочку (я не поклонник насмешки, когда это не необходимо), просто используйте инструмент ORM для создания, читайте, обновление, и удалите типичный объект/запись и проверьте операцию с помощью прямых SQL-операторов на (тест) база данных. Тот путь, если сторонний поставщик более поздние обновления что-то, что повреждает основную функциональность, которую Вы будете знать об этом, и новые разработчики к Вашему проекту, может легко видеть, как использовать инструмент ORM от примеров модульного теста.

«Я однажды слышал, как кто-то сказал, что если он напишет более 10 строк кода без тестов, то он начнет неуверенно, будет ли работать код, который он только что написал».

Это человек представляет опасность для себя. Немедленно удалите их из кода.