Тестирование в стиле TSA

[Davert]

Да-да, хороший пост. Тот же Ryan Bates в своем твиттере написал, что 90% всех его багов ловят acceptance тесты. Пост очень добавляет рационализма в словечки типа TDD и BDD.

[ka8725]

Можете скинуть ссылку на его твит этот? Очень нужно. Спасибо!

[Aux]

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

[alexeygrigorev]

В некоторых конторах практикуется программирование на пару с QA, и последний сразу по ходу дела показывает, в каких местах код может сломаться и какие тесты написать надо.

[VasilioRuzanni]

Не нужно путать функциональные/приемочные тесты и юнит-тесты, на которых строится TDD.

[Aux]

TDD вообще глупость — больше работы, больше ошибок. Тестами должен быть занят отдел QA.

[VasilioRuzanni]

О, сразу видно, кто тут вообще не знает, что такое TDD, да и вообще юнит-тестирование в целом.

[AlexMac]

Видимо вы плохо знакомы с подходом TDD. Данный подход подразумевает круговой процесс:
тест-код-рефакторинг — тест…
И реализоваываться он должен одним человеком. Соответсвенно если отдать этот процесс ребятам из QA, это будет уже не TDD, а Unit tests.

[FB3]

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

[andrewsch]

Обычно имеет смысл писать тест, который проверяет базовую функциональность вновь добавляемой фичи — чтобы просто не поднимать весь сервер и не проверять ручками через браузер.

А далее, при поддержке и развитии, основное правило — каждый обнаруженый баг должен быть покрыт новым тестом (по возможности).

Поддержка самих тестов не отнимает много времени — они редко ломаются, и если ломаются, то по делу. Вот запуск всех тестов — это да… у нас уже минут 20 занимает полный прогон. Но их, собственно, должен билд-сервер автоматом гонять время от времени.

[mekegi]

«Запах медленных тестов». Разбейте тесты на несколько групп — типа «быстрые», «средние», «медленные». Разработчики будут запускать каждый раз у себя быстрые тесты. Средние могут запускать пару раз в день. Ну а группа медленных тестов пусть запускается при выкладке кода на тестовый сервак.
Ну и совсем уже капитанство — отрефакторьте медленные тесты чтобы они были пошустрее.

[andrewsch]

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

[UshkurKayuf]

А что, правда, что Cucumber так плох? Как раз собирались начать его использовать? У кого-нибудь есть опыт работы с ним?

[Davert]

DHH просто не любит ни RSpec ни Cucumber. Это его личное )
Но я, например, тоже не люблю.
Кто-то любит…
На вкус и цвет…

[heel]

Да, я тоже был весьма удивлен от его слов: «It makes me sad when I see people who are using Rspec and Cucumber»

Rspec очень мощный инструмент для тестирования. Cucumber все таки на любителя больше

[Davert]

Я вот так и не понял в чем принципиальное отличие RSpec от его любимого Test::Unit? То что текст иначе пишется? Если использовать чисто для тестирования, то две совершенно похожих тулзы.

[heel]

Основное отличие в том, что Rspec это DSL, а Test:Unit скорее plain ruby

[Davert]

Ок. Это как раз не фича RSpec, в DSL труднее разобраться.
Ну а в чем принципиальное отличие assert от should?

[heel]

Лично для меня, тесты на Rspec более читабельны. Много людей пользуются и больше документации.

[murr]

Если вам действительно интересно, а не троллинга ради, то принципиальное отличие: писать в BDD стиле в РСпек очень просто, дело скорее в способе организации кода. Правильно написанный код RSpec вообще можно сразу же гнать в документацию, и читать такие тесты одно удовольствие, в отличии от простыни ассертов.

Посмотрите отличную презентацию kerryb.github.com/iprug-rspec-presentation/

[xxxYURAxxx]

ничего в нем страшного нет
он просто медленнее и поэтому надо тестировать с умом

[heel]

Писал как-то сценарии на cucumber, смысла в этом особо не нашел. Возможно, сказывается еще то, что английский хоть и на хорошем уровне, но все таки не родной

[SageScs]

Cucumber позволяет писать сценарии и на русском

[d7k]

Тесты не бесплатны, но удешевляемы.

Сколько раз натыкался на то, что какая-то логика изначально не тестировалась из-за цены: это тестировать дорого, я как нибудь по старинке. Во время развития она начинала, то тут, то там сбоить. В какой-то момент понимаешь, что затраты на тесты были бы ниже. И что так дальше нельзя — пишешь тесты.

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

[paladin]

По видимому, маятник моды уже начинает свой ход в обратную сторону.

[AlexMac]

TDD очень мощная вещь, но только при грамотном использовании. TDD это не просто «тестирование кода», а по сути — иной способой разработки программы (сайта).
В ruby вообще очень просто и приятно использовать TDD (в отличие от компилирумых языков). Есть отличные Gem'ы для TDD разработки:
RSpec, Factorial_Girl, Guard_RSPec

[Davert]

Я бы ещё добавил Timecop. Такого в других даже динамичных языках таки нет.

[deilux]

Спасибо

[Litiy]

Еще Spork — форкинг процессов в guard перед запуском, очень ускоряет TDD.
DHH в этой статье будто мои мысли прочитал. Как раз себя сейчас приучаю к контрибьютингу и тестированию.

[ka8725]

Потрясающая статья! Не понимаю почему так мало плюсов…

[bevzuk]

Стоимость написания тестов сильно уменьшается при использовании DSL (Domain Specific Language).
Правда написание самого DSL тоже не бесплатно :)

[Renius]

Забыли самое важное: не тестируйте функционал рельсы.