Нужно ли все проверять?

28

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

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

Маттео Пальяцци
источник
9
Это действительно не вопрос рубина на рельсах. это больше вопрос TDD.
Джон Страйер
4
@JonStrayer: Это так? Вы уверены, что для RoR ответ будет таким же, как и для .NET? Я хотел бы предположить, что по замыслу RoR сознательно снизил стоимость тестирования, а отсутствие безопасности типов в виде компилятора значительно увеличивает выгоду тестирования.
фунтовые
1
По какой-то причине этот вопрос заставляет меня захотеть опубликовать макрос с изображением капитана Нерона, кричащего "ТЕСТ ВСЕ !!!"
Мейсон Уилер
3
Не видеть реального преимущества в написании тестов и написании их из слепой веры не очень правильно. Продолжайте без написания тестов, через некоторое время вы столкнетесь с неожиданной регрессией и поймете, почему вы тестируете.
ZJR
1
Подождите, пока вы не решите реструктурировать свой код. Каждый раз, когда вносятся значительные изменения, вам необходимо проверить функциональность. Без тестов вам нужно будет пройти через ваше приложение и проверить все функции вручную. Представьте еще одно большое обновление, и вам придется делать это снова. Модульные тесты - это просто «дешевый» способ убедиться, что все работает так, как ожидалось.
Эван Плейс,

Ответы:

47

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

Итак, с учетом этого, каково поведение статической страницы и каков интерфейс?

Мой первый ответ будет «нет» и «нет».

Джон Стрейер
источник
так нет тестов на статические страницы?
Маттео Пальяцци
TDD, в некоторой степени, о дизайне. Но вам все еще нужна архитектура. Без архитектуры сложно представить, как можно вырасти органично из множества испытаний.
Роберт Харви
@MatteoPagliazzi В зависимости от уровня тестирования (юнит-тесты / интеграционные тесты / и т. Д.), Возможно один или два, для подтверждения доступности статических страниц. Но это слишком высокий уровень для юнит-тестов.
Изката
1
@RobertHarvey Я не говорил, ничего не проверяй. Я сказал, что не тестируйте статические страницы.
Джон Страйер
@JonStrayer: TDD'еры склонны держать TDD как магический эликсир для дизайна; Я прошу прощения, если это не то, что вы имели в виду. :)
Роберт Харви
32

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

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

Почти невозможно ответить на эти вопросы в общем IMO.

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

Дуг Т.
источник
Кроме того, я бы предположил, что ошибки на статической странице было бы НАМНОГО легче исправить, чем логические ошибки, ошибки проектирования и тип вещей, которые TDD обычно используют для предотвращения. Обнаружение и исправление ошибок статических страниц, скорее всего, будет довольно простым, и у меня сложилось впечатление, что TDD используется для сокращения обоих этих процессов, когда они занимают больше времени, чем хотелось бы. : D
Гордон Густафсон
Я бы не предположил это. Если вы когда-либо сталкивались с неясным поведением версии браузера или странными проблемами с памятью JavaScript, вы, вероятно, получили достаточно тренировки. Чаще, в качестве внутренних языков может быть немного более надежным и стандартным. иногда. Может быть, вы говорите о статических, как в HTML и не JavaScript, хотя.
Майкл Даррант
8

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

Брюс Эдигер
источник
«тогда вы можете быть уверены, что добавление нового кода не приведет к тому, что код на месте перестанет работать», поэтому я не должен касаться какого-либо фрагмента кода, который я написал ранее, и просто добавлять новые методы?
Маттео Пальяцци
Ну нет. Но непредвиденные и незапланированные зависимости между кодом, который в настоящее время «работает», могут привести к проблемам, если вы добавите новый код, который изменяет эти зависимости. Кроме того, если вы ошиблись в тесте, что, на мой взгляд, является довольно распространенным явлением, вы должны изменить сам тест, а затем, возможно, изменить код, полученный из этого теста.
Брюс Эдигер
@ Энди Это абсолютная чепуха. Тестирование установщиков и получателей свойств является тривиальным и жизненно важным. Если они не работают, как правило, весь класс разваливается. Например, в многопоточном приложении, если набор не предотвращает одновременное получение, вы получите проблему с поврежденными данными, которая может занять несколько часов, чтобы добраться до сути, потому что источник данных будет правильным, но результат получения не будет или если ваш набор не сможет обновить время обновления, то ваши данные могут стать невозможными для синхронизации. Если бы сеттеры и геттеры были действительно тривиальны, вы могли бы просто сделать собственность публичной
deworde
@deworde Боюсь, что безопасность членов экземпляра не так уж часто встречается. Более обычно контролировать доступ к не-безопасному типу, чем пытаться сделать их безопасными для потоков. Как бы то ни было, то, что тестировать, - это выгодно, как говорится в другом ответе. вы можете потратить время на написание тестов для геттеров или сеттеров или можете проверить реальное поведение, которое ваша система должна инкапсулировать.
Энди
3

Да, вы должны проверить все ...

Вам не нужно будет писать автоматические тесты для всего. Для ваших статических страниц, посмотрите на использование Selenium http://seleniumhq.org/, чтобы убедиться, что все правильно.

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

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

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

Хотя тестировать все невозможно (особенно с небольшими группами и большими системами), это не означает, что вы вообще пропускаете тестирование. Стоит ли тестировать? См. Раздел «Раннее обнаружение неисправностей» в разделе « Вики-тестирование программного обеспечения» .

Без шансов
источник
2

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

Chriseyre2000
источник
2

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

Такие языки, как Delphi , C ++, VB.NET и т. Д., Являются скомпилированными языками, и ваш компилятор будет сталкиваться с множеством ошибок, таких как опечатки, при вызовах метода. В Ruby on Rails вы будете знать только, если в вашем коде есть опечатка или ошибка, если эта конкретная строка кода запущена или вы используете IDE, которая отображает визуальные предупреждения.

Поскольку КАЖДАЯ отдельная строка кода важна (иначе ее не будет), вы должны протестировать каждый метод, который вы пишете. Это намного проще, чем кажется, если вы следуете некоторым основным инструментам TBDD.

Я обнаружил, что Rails Cast of Ryan Cast на « Как я тестирую» был для меня бесценным и действительно подчеркнул простоту TBDD, если все сделано правильно.

jamesc
источник
1

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

wessiyad
источник
2
да ... но, например, на статической странице, что я должен проверить? существование этого? что контент и ссылки существуют? возможно я ошибаюсь, но это кажется пустой тратой времени ...
Маттео Пальяцци
1
Я склонен думать, что методология TDD применяется к вашей логике. Является ли ваша статическая страница HTML-файлом? Взгляд MVC, который никогда не меняется? Если в последнем случае, я думаю, вы могли бы проверить, что ваш контроллер возвращает правильное представление. Я думаю, что более важно помнить, что TDD должен помогать вам развиваться в соответствии с вашими требованиями, а не просто «тестировать» ...
wessiyad
Я предполагаю, что вы просто обслуживаете статическую страницу с компонентом фреймворка. Если ни один из ваших методов не касается этой страницы, на самом деле проверять нечего. Вам также не нужно тестировать Rails. Я думаю, что кто-то покрыл это.
Эрик Реппен
0

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

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

Но не являются ли гигантские цепочки непредсказуемых связанных зависимостей продуктом дрянного дизайна?

Так что это?

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

«Программа для интерфейса, а не реализация»

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

А также:

«Пользуйся композицией объектов по наследованию классов»

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

И вот тут я дохожу до того, что меня беспокоит. TDD действительно помогает проектировать или это допускает плохую архитектуру? Мне кажется, что у него есть потенциал для самореализующейся стратегии. Чем больше ваша команда не должна нести ответственность за плохую архитектуру, тем более полезными становятся эти компоненты детального тестирования, но в конечном итоге ваше приложение становится все более и более мощным PITA для работы (при условии, что они никогда не задумывались об архитектуре в первые место). А неспособность признать последствия этого - дело рук, всегда самая дорогая ошибка, которую вы можете совершить, работая над приложением, которое должно быть обновлено и модифицировано с течением времени.

Эрик Реппен
источник
-1

Чтобы ответить на вопрос, подумайте, что здесь может пойти не так. В частности, если вы измените «код» (разметка / что угодно), как вы будете уверены, что не сломали страницу. Ну, для статической страницы:

  • это может не сделать
  • это может сделать неправильно
  • JS может не загружаться
  • пути к изображениям могут не работать
  • ссылки могут быть сломаны

Лично я бы порекомендовал:

  • напишите тест на селен [1], который проверяет наличие одной строки на странице (если возможно, ближе к нижней). Это подтверждает, что он оказывает.
  • проверьте, нет ли ошибок JS (я думаю, что селен позволяет это)
  • запустить статические страницы через HTML-валидатор и, если возможно, средство проверки ссылок.
  • Я не нашел инструмент, который мне нравится проверять JS, но вы можете найти успех с jslint или jshint.

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

Пол Биггар
источник
-1

Просто чтобы добавить ко всем и без того отличным ответам, вот мои мысли о том, что тестировать, а что не тестировать:

Сделать тест:

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

Не проверять:

  • константы
  • презентация

Так что нет смысла проводить тест, который говорит:

assert wibble = 3

и некоторый код, который говорит

wibble = 3

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

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

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

hwjp
источник