Comments 32
Да-да, хороший пост. Тот же Ryan Bates в своем твиттере написал, что 90% всех его багов ловят acceptance тесты. Пост очень добавляет рационализма в словечки типа TDD и BDD.
Моё мнение — тесты должны писать ребята из отдела QA. Это их работа — четко знать что надо покрывать тестами, а что избыточно. И именно у этих ребят свежий взгляд на ваш код.
В некоторых конторах практикуется программирование на пару с QA, и последний сразу по ходу дела показывает, в каких местах код может сломаться и какие тесты написать надо.
Не нужно путать функциональные/приемочные тесты и юнит-тесты, на которых строится TDD.
Видимо вы плохо знакомы с подходом TDD. Данный подход подразумевает круговой процесс:
тест-код-рефакторинг — тест…
И реализоваываться он должен одним человеком. Соответсвенно если отдать этот процесс ребятам из QA, это будет уже не TDD, а Unit tests.
тест-код-рефакторинг — тест…
И реализоваываться он должен одним человеком. Соответсвенно если отдать этот процесс ребятам из QA, это будет уже не TDD, а Unit tests.
Обычно имеет смысл писать тест, который проверяет базовую функциональность вновь добавляемой фичи — чтобы просто не поднимать весь сервер и не проверять ручками через браузер.
А далее, при поддержке и развитии, основное правило — каждый обнаруженый баг должен быть покрыт новым тестом (по возможности).
Поддержка самих тестов не отнимает много времени — они редко ломаются, и если ломаются, то по делу. Вот запуск всех тестов — это да… у нас уже минут 20 занимает полный прогон. Но их, собственно, должен билд-сервер автоматом гонять время от времени.
А далее, при поддержке и развитии, основное правило — каждый обнаруженый баг должен быть покрыт новым тестом (по возможности).
Поддержка самих тестов не отнимает много времени — они редко ломаются, и если ломаются, то по делу. Вот запуск всех тестов — это да… у нас уже минут 20 занимает полный прогон. Но их, собственно, должен билд-сервер автоматом гонять время от времени.
«Запах медленных тестов». Разбейте тесты на несколько групп — типа «быстрые», «средние», «медленные». Разработчики будут запускать каждый раз у себя быстрые тесты. Средние могут запускать пару раз в день. Ну а группа медленных тестов пусть запускается при выкладке кода на тестовый сервак.
Ну и совсем уже капитанство — отрефакторьте медленные тесты чтобы они были пошустрее.
Ну и совсем уже капитанство — отрефакторьте медленные тесты чтобы они были пошустрее.
да понятно все… так и делаем… конкретно на рефакторинг просто времени особо нет… а еще там есть ряд тестов, которые тупо в цикле бегут по базе и проверяют интерпретируемые сценарии — сложность там квадратичная, и тормоза из-за интерпретатора, и один такой тест легко минуту занимает, и как его оптимизировать, не совсем ясно… так что только деление на медленные и быстрые тесты, да…
А что, правда, что Cucumber так плох? Как раз собирались начать его использовать? У кого-нибудь есть опыт работы с ним?
DHH просто не любит ни RSpec ни Cucumber. Это его личное )
Но я, например, тоже не люблю.
Кто-то любит…
На вкус и цвет…
Но я, например, тоже не люблю.
Кто-то любит…
На вкус и цвет…
Да, я тоже был весьма удивлен от его слов: «It makes me sad when I see people who are using Rspec and Cucumber»
Rspec очень мощный инструмент для тестирования. Cucumber все таки на любителя больше
Rspec очень мощный инструмент для тестирования. Cucumber все таки на любителя больше
Я вот так и не понял в чем принципиальное отличие RSpec от его любимого Test::Unit? То что текст иначе пишется? Если использовать чисто для тестирования, то две совершенно похожих тулзы.
Основное отличие в том, что Rspec это DSL, а Test:Unit скорее plain ruby
Ок. Это как раз не фича RSpec, в DSL труднее разобраться.
Ну а в чем принципиальное отличие assert от should?
Ну а в чем принципиальное отличие assert от should?
Лично для меня, тесты на Rspec более читабельны. Много людей пользуются и больше документации.
Если вам действительно интересно, а не троллинга ради, то принципиальное отличие: писать в BDD стиле в РСпек очень просто, дело скорее в способе организации кода. Правильно написанный код RSpec вообще можно сразу же гнать в документацию, и читать такие тесты одно удовольствие, в отличии от простыни ассертов.
Посмотрите отличную презентацию kerryb.github.com/iprug-rspec-presentation/
Посмотрите отличную презентацию kerryb.github.com/iprug-rspec-presentation/
ничего в нем страшного нет
он просто медленнее и поэтому надо тестировать с умом
он просто медленнее и поэтому надо тестировать с умом
Писал как-то сценарии на cucumber, смысла в этом особо не нашел. Возможно, сказывается еще то, что английский хоть и на хорошем уровне, но все таки не родной
Тесты не бесплатны, но удешевляемы.
Сколько раз натыкался на то, что какая-то логика изначально не тестировалась из-за цены: это тестировать дорого, я как нибудь по старинке. Во время развития она начинала, то тут, то там сбоить. В какой-то момент понимаешь, что затраты на тесты были бы ниже. И что так дальше нельзя — пишешь тесты.
Если бы на момент начала написания логики имел бы набор инструментов (примитивов, библиотек и др. байды) помогающих писать тесты для конкретной области, вопрос писать или нет бы не стоял. Поэтому, по крайней мере, пробую писать. Что бы получить пищу для размышления, «почему сложно» и как по необходимости эту сложность решить.
Сколько раз натыкался на то, что какая-то логика изначально не тестировалась из-за цены: это тестировать дорого, я как нибудь по старинке. Во время развития она начинала, то тут, то там сбоить. В какой-то момент понимаешь, что затраты на тесты были бы ниже. И что так дальше нельзя — пишешь тесты.
Если бы на момент начала написания логики имел бы набор инструментов (примитивов, библиотек и др. байды) помогающих писать тесты для конкретной области, вопрос писать или нет бы не стоял. Поэтому, по крайней мере, пробую писать. Что бы получить пищу для размышления, «почему сложно» и как по необходимости эту сложность решить.
По видимому, маятник моды уже начинает свой ход в обратную сторону.
TDD очень мощная вещь, но только при грамотном использовании. TDD это не просто «тестирование кода», а по сути — иной способой разработки программы (сайта).
В ruby вообще очень просто и приятно использовать TDD (в отличие от компилирумых языков). Есть отличные Gem'ы для TDD разработки:
RSpec, Factorial_Girl, Guard_RSPec
В ruby вообще очень просто и приятно использовать TDD (в отличие от компилирумых языков). Есть отличные Gem'ы для TDD разработки:
RSpec, Factorial_Girl, Guard_RSPec
Потрясающая статья! Не понимаю почему так мало плюсов…
Стоимость написания тестов сильно уменьшается при использовании DSL (Domain Specific Language).
Правда написание самого DSL тоже не бесплатно :)
Правда написание самого DSL тоже не бесплатно :)
Забыли самое важное: не тестируйте функционал рельсы.
Sign up to leave a comment.
Тестирование в стиле TSA