Я собираюсь начать свой первый настоящий проект в Ruby on Rails и заставляю себя писать тесты TDD . Я не вижу реальных преимуществ в написании тестов, но так как это кажется очень важным, я попробую.
Нужно ли тестировать каждую часть моего приложения, включая статические страницы?
Ответы:
TDD не о тестировании, а о дизайне. Написание тестов заставляет задуматься о том, как должен работать класс и какой интерфейс вам нужен. Тесты - это приятный побочный эффект, который облегчает последующий рефакторинг.
Итак, с учетом этого, каково поведение статической страницы и каков интерфейс?
Мой первый ответ будет «нет» и «нет».
источник
Это всегда анализ затрат и выгод. Какова стоимость ломающейся функции для вас? Если стоимость высока, тогда тестируйте хорошо и тщательно. Если стоимость низкая, проведите тестирование незначительно или вообще не проводите тестирование.
Существует также стоимость времени выхода на рынок, чтобы рассмотреть. Может быть, вам лучше поставить работоспособную функцию, чем опоздать с доставкой полностью работающей функции
Почти невозможно ответить на эти вопросы в общем IMO.
Я думаю, что более важно сохранить возможность тестирования в том случае, если какая-то функция окажется более важной, чем вы изначально предполагали.
источник
Я бы сказал "да". Если у вас есть тесты, охватывающие даже самые простые функции и код, тогда вы можете быть уверены, что добавление нового кода не приведет к тому, что код на месте перестанет работать. Точно так же, вставляя тест для каждой ошибки, с которой вы сталкиваетесь, удерживаете от регрессии.
источник
Да, вы должны проверить все ...
Вам не нужно будет писать автоматические тесты для всего. Для ваших статических страниц, посмотрите на использование Selenium http://seleniumhq.org/, чтобы убедиться, что все правильно.
Исходя из моего опыта, некоторые вещи в интерфейсе практически невозможно написать для тестовых случаев, но именно поэтому вы действительно захотите протестировать, используя глазное яблоко Mark 1.
источник
Тестирование так же важно, как и кодирование. Вы должны услышать поговорку «Если что-то может пойти не так, это будет». INMO, из множества методов разработки программного обеспечения, которые используются для повышения качества, тестирование является наиболее ценным средством, помогающим вам быстро находить проблемы.
Хотя тестировать все невозможно (особенно с небольшими группами и большими системами), это не означает, что вы вообще пропускаете тестирование. Стоит ли тестировать? См. Раздел «Раннее обнаружение неисправностей» в разделе « Вики-тестирование программного обеспечения» .
источник
Тесты TDD также могут быть живыми спецификациями, если они написаны таким образом. Названия методов тестирования должны иметь смысл для бизнес-пользователя.
источник
Как уже упоминалось, в тестировании Ruby on Rails это гораздо важнее, чем в (большинстве) других языках. Это связано с отсутствием компилятора.
Такие языки, как Delphi , C ++, VB.NET и т. Д., Являются скомпилированными языками, и ваш компилятор будет сталкиваться с множеством ошибок, таких как опечатки, при вызовах метода. В Ruby on Rails вы будете знать только, если в вашем коде есть опечатка или ошибка, если эта конкретная строка кода запущена или вы используете IDE, которая отображает визуальные предупреждения.
Поскольку КАЖДАЯ отдельная строка кода важна (иначе ее не будет), вы должны протестировать каждый метод, который вы пишете. Это намного проще, чем кажется, если вы следуете некоторым основным инструментам TBDD.
Я обнаружил, что Rails Cast of Ryan Cast на « Как я тестирую» был для меня бесценным и действительно подчеркнул простоту TBDD, если все сделано правильно.
источник
Если вы действительно используете методологию TDD, то вы не пишете код, не пройдя сначала тестовый модуль, который вы пытаетесь выполнить.
источник
Я бы сказал, чтобы не начинать с TDD. Примите обоснованное решение, когда вы потратите больше времени на изучение стратегий архитектуры в целом. TDD не позволит вам пропустить эту домашнюю работу, хотя вы можете начать верить, что она делает.
Вот моя проблема с этим. Когда вы говорите, что кажется, что потрачено много времени на вещи, которые никогда не сломают TDD, говорят, что вы оцените это, когда одна вещь, которую вы не ожидали в огромной цепочке зависимостей, будет разрушена. Когда вы указываете на то, что невозможно предсказать такие вещи до того, как вы напишите свое приложение, и это ... почему мы тестируем, они говорят вам, что это действительно больше о дизайне, а не тестировании, даже если тестирование пригодится.
Но не являются ли гигантские цепочки непредсказуемых связанных зависимостей продуктом дрянного дизайна?
Так что это?
Вот мысль. Давайте не будем в первую очередь иметь огромные сложные цепочки зависимостей, рассматривая следующие два принципа объектно-ориентированного проектирования из Design Patterns:
То есть ваши объекты не должны заботиться о том, кто выполняет призвание или как они были сделаны. Только то, что были введены правильные аргументы и что методы, которые они вызывают из других объектов, направлены на работу, как и ожидалось. Ваша цепочка зависимостей в большинстве случаев должна находиться в одной точке соединения, вызове метода со стороны вызывающей стороны и месте, где аргументы попадают в ваши методы. Вот где вы регистрируетесь, проверяете и отправляете полезные сообщения для отладки, когда дела идут плохо.
А также:
Кто дурачок? Парень, который сделал что-то с классом в запутанной каскадной схеме наследования, включающей около 30 классов, что привело к поломке кейса, или разработчик, который первым придумал эту архитектуру? TDD может помочь вам быстрее разобраться в проблемах в этой падающей башне класса Пизы, чем без вас, но делает ли это менее болезненной попытку изменить одну из конечных точек этого кода в следующий раз?
И вот тут я дохожу до того, что меня беспокоит. TDD действительно помогает проектировать или это допускает плохую архитектуру? Мне кажется, что у него есть потенциал для самореализующейся стратегии. Чем больше ваша команда не должна нести ответственность за плохую архитектуру, тем более полезными становятся эти компоненты детального тестирования, но в конечном итоге ваше приложение становится все более и более мощным PITA для работы (при условии, что они никогда не задумывались об архитектуре в первые место). А неспособность признать последствия этого - дело рук, всегда самая дорогая ошибка, которую вы можете совершить, работая над приложением, которое должно быть обновлено и модифицировано с течением времени.
источник
Чтобы ответить на вопрос, подумайте, что здесь может пойти не так. В частности, если вы измените «код» (разметка / что угодно), как вы будете уверены, что не сломали страницу. Ну, для статической страницы:
Лично я бы порекомендовал:
Суть в том, что вам нужно что-то повторяемое, простое в использовании, и оно будет автоматически запускаться в вашем тестовом центре.
источник
Просто чтобы добавить ко всем и без того отличным ответам, вот мои мысли о том, что тестировать, а что не тестировать:
Сделать тест:
Не проверять:
Так что нет смысла проводить тест, который говорит:
и некоторый код, который говорит
Кроме того, нет смысла тестировать презентационные вещи, например, отображается ли значок синим барвинок, какой шрифт вы использовали для заголовков и так далее ...
Итак, вы спрашиваете: «Должен ли я тестировать статические страницы», и ответ таков: вы проверяете их, поскольку они являются частью функциональности, бизнес-логики или поведения вашего сайта.
Итак, в нашем приложении у нас есть тест, который проверяет, доступны ли условия и положения в каждой части сайта - для анонимных пользователей, для зарегистрированных пользователей, с панели инструментов, на экранах приложений и т. Д. Он просто проверяет, что есть ссылка, называемая «положения и условия» на каждой странице, что эта ссылка работает, а затем тест говорит, что когда она попадает на страницу, она «выглядит как» правила и условия - достаточно, чтобы убедиться, что это правильная страница, без «тестирования константы» или «тестирования презентации» ... чтобы вы могли проверить правильность текста, например, без проверки определенного размера шрифта или расположения текста ...
источник