Важны ли макеты и высокое тестовое покрытие? - PullRequest
4 голосов
/ 21 октября 2009

Макетные рамки, например EasyMock, упростите добавление фиктивных зависимостей. Сказав это, использование их для обеспечения того, как разные методы на определенных компонентах вызываются (и в каком порядке), кажется мне плохим. Он выставляет поведение на тестирование класса, что усложняет поддержку производственного кода. И я действительно не вижу выгоды; мысленно я чувствую, что прикован к тяжелому мячу.

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

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

Уважаемые SOERS, что вы думаете по этому поводу?

Ответы [ 5 ]

3 голосов
/ 22 октября 2009

Я прочитал 2 вопроса:

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

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

Тесты, которые проверяют только одну вещь, легче понять и поддерживать.

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

Должен ли быть одержим тестовым покрытием?

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

Общая статистика покрытия модульных тестов? Не особенно интересно, пока они высокие.

100% охват модульным тестом для всей системы? Совсем не интересно.

2 голосов
/ 21 октября 2009

Я согласен - я склонен в большей степени склоняться к проверке состояния, а не к проверке поведения (слабая интерпретация классического TDD при использовании двойных тестов).

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

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

1 голос
/ 21 октября 2009

Это зависит от того, как вы моделируете домен (ы) вашей программы.

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

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

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

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

1 голос
/ 21 октября 2009
  1. Какова вероятность того, что во время сопровождения вашего кода какой-нибудь младший сотрудник нарушит часть кода, выполняющего «вызов контроллера таким и таким методом в определенном порядке»?

  2. Какова будет цена для вашей организации, если такое произойдет - при остановке производства, отладке / исправлении / повторном тестировании / повторном выпуске, правовом / финансовом риске, репутационном риске и т. Д. *

Теперь, умножьте № 1 и № 2 и проверьте, стоит ли ваше нежелание достичь разумного количества тестового покрытия.

Иногда этого не будет (вот почему в тестировании есть понятие точки убывающей отдачи).

например. если вы поддерживаете веб-приложение, которое не является критически важным для производства и имеет 100 пользователей, которые имеют обходной путь, если приложение сломано (и / или может выполнить простой и немедленный откат), то тратить 3 месяца на полное покрытие тестирования этого приложения, вероятно, не -sensical.

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

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

1 голос
/ 21 октября 2009

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

...