Почему мои модульные тесты так дороги? [Дубликат]

    

У этого вопроса уже есть ответ:

    

Я разработчик Java, работая над небольшим проектом. У нас три человека в команде, у нас есть бюджет на 3 месяца кодирования (+ некоторое время для аналитика, менеджера проекта и команды QA). Это небольшой проект, бюджет действительно ограничен. В нашей организации есть определенная поддержка для проведения модульных тестов, но я не встречал экспертов в этой области. Мотивированный книгами и дискуссиями, я начал выполнять модульные тесты. У меня ограниченный опыт работы с фреймворками и подходами, поэтому я не тестирую каждого геттера, я сосредоточен на бизнес-коде, я использую Mockito и плагин MoreUnit Eclipse для создания скелета и Mocks. Я разрабатываю свой код заранее, я использую множество шаблонов дизайна, я сохраняю свой код чистым, с короткими методами, я уважаю принцип Single Responsibility Principe, и у меня есть гораздо больше публичных методов, чем частные. Это не идеально, но это лучшее, что я могу сделать после 5 лет коммерческого опыта в одной корпорации и одной компании среднего размера.

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

Что мне не хватает? Я делаю это неправильно?

Изменить: Чтобы добавить некоторые числа, я трачу около 80% времени на проектирование и кодирование, а 20% - на модульное тестирование, поэтому только небольшое количество моего кода покрывается тестами. Я пытаюсь выполнить единичный тест за 1,5 месяца, обычно после того, как я закончу некоторые функции и грубо испытаю на своей локальной машине разработки.

6 голосов | спросил Michal 7 PMpTue, 07 Apr 2015 23:03:17 +030003Tuesday 2015, 23:03:17

5 ответов


13

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

Единичные тесты и другие автоматические тесты покажут свою ценность намного яснее, когда вы

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

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

ответил Doc Brown 8 AMpWed, 08 Apr 2015 00:04:36 +030004Wednesday 2015, 00:04:36
11

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

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

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

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

ответил leo 8 AMpWed, 08 Apr 2015 00:29:51 +030029Wednesday 2015, 00:29:51
7
  

Почему мои модульные тесты так дорого?

По той же причине развод настолько дорог:

Это того стоит.

По моему опыту (bizdev, C # /Java более десяти лет), для написания модульных тестов для кода требуется примерно половина времени, как написания самого кода, так что 33% от вашего общего времени кодирования. Некоторые вещи будут больше. Некоторые вещи будут меньше. Когда вы просто учитесь писать модульные тесты, это будет медленнее, чем «нормальное» кодирование. Это (по моему опыту) обеспечивает сладкое пятно для большинства кодов между затраченным временем и эффективным тестированием. Обычно это будет хороший 70-80% охват кода, дайте или возьмите. В некоторых средах может потребоваться более строгое качество. Меньше может понадобиться меньше.

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

  

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

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

ответил Telastyn 7 PMpTue, 07 Apr 2015 23:36:12 +030036Tuesday 2015, 23:36:12
1

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

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

ответил Julia Hayward 8 AMpWed, 08 Apr 2015 10:49:34 +030049Wednesday 2015, 10:49:34
1

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

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

Некоторые инструменты, такие как JUnit и mockito, являются общими для обоих подходов (хотя чрезмерное использование mocks быстро приведет к испытаниям, которые бесполезны, как и все, кроме лесов). Другие инструменты, такие как quickcheck и

ответил soru 8 PMpWed, 08 Apr 2015 13:31:00 +030031Wednesday 2015, 13:31:00

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132