Какие виды модульных тестов приносят наибольшую пользу в бизнесе?

Question

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

Answer 1

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

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

Answer 2

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

Пользовательский интерфейс <----> Бизнес <---> Данные

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

Тесты, которые можно использовать во многих местах. Примеры из моего текущего проекта:

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

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

Answer 6

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

Answer 7

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

Answer 8

Обсуждается в SO Podcast 41 - в данный момент эта часть отсутствует в расшифровке . Ответы в блоге содержат дальнейшее обсуждение значения охвата модульного теста.

• Джоэл обеспокоен тем, что чрезмерное TDD (скажем, от 90% до 100% покрытия тестированием) сокращает время от других действий, которые могут принести пользу программному продукту, таких как улучшение юзабилити или дополнительных функций, которые требуют пользователи.
• Модульные тесты абсолютно полезны как форма «поедания собственного собачьего корма» и документирования поведения вашей системы. Даже если вы полностью игнорируете фактические результаты тестов, они по-прежнему ценны как документация и дают вам свежий взгляд на вашу базу кода.
• Джоэл отмечает сложность тестирования пользовательского интерфейса (веб-или исполняемого) по сравнению с тестированием кода за пользовательским интерфейсом. Классический способ сделать это, вероятно, описан в статье «Искусство программирования в UNIX», где вы начинаете с приложения командной строки, которое принимает и выплевывает текст. GUI - это просто слой, который вы вставляете поверх приложения командной строки, что обеспечивает отличную тестируемость - но, возможно, не такие уж хорошие приложения в долгосрочной перспективе. Что важнее?

Answer 9

Чтобы попытаться ответить на мой собственный вопрос, вот модули, которые я нашел достойным тестирования:

а) Любое из деловых правил. В моем текущем приложении бизнес-правила выводятся из бизнес-объектов.

б) Любой из виртуальных атрибутов бизнес-объектов. Часто эти виртуальные атрибуты включают алгоритмы.

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

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

e) Любой из наших уровней перевода, где мы переводим из одного типа представления данных в другой, такой как POJO-XML