Rspec - как запустить одну спецификацию

[shat...@gmail.com]

Всем привет.
В доке по рспекам нашёл как запускать все спеки или только один спек
файл.
Но у меня спек файл состоит из набора спецификаций типа it "should do
smthg" do ... end"
Подскажите плиз как, запустить одну спецификацию в файле, навроде как
при запуске теста с ключом -n.
Спасибо. Пока.

[Timur Vafin]

shat...@gmail.com пишет:

А через просто spec?
spec mega_test.rb

--
Timur Vafin mailto:tim...@gmail.com
http://flatsourcing.com

[shat...@gmail.com]

Я ж писал - так запускается один спек файл, а у меня в этом файле
несколько блоков
it "should " do
...
end
вот пытаюсь выяснить как запустить один такой блок

[Timur Vafin]

shat...@gmail.com пишет:

Разнести на несколько файлов? Закомментить не нужное и запустить?

[shat...@gmail.com]

ну напрмер у меня есть файл - спецификация модели
МояМодель.спек - в ней есть одна спецификация для метода ПервыйМетод
я добавляю спецификацию для метода ВторойМетод и что - коментарить
первый блок? А если там уже 5 блоков?
и создавать много файлов для одной модели не красиво, по-моему, как
минимум генератор создаёт же один спек файл.

[Timur Vafin]

shat...@gmail.com пишет:

А какая причина того, что нельзя запускать все сразу? Медленно и тормозит?

[Maxim Kulkin]

Не надо ничего комментировать.. сколько есть спецификаций, столько пусть там и
торчит (подразумевается, что все спецификации относятся к одному классу)...

А разделять может понадобиться только для отладки и т.п. (хотя есть autotest и
все такое)...

[liquidautumn]

shat...@gmail.com wrote:
> Всем привет.
> В доке по рспекам нашёл как запускать все спеки или только один спек
> файл.
> Но у меня спек файл состоит из набора спецификаций типа it "should do
> smthg" do ... end"
> Подскажите плиз как, запустить одну спецификацию в файле

зачем?

[Michael Klishin]

В Текстмейте, например, есть RSpec bundle
(лежит прямо в репозитории RSpec), там
есть такое: Command + R, 1 (scope: Ruby).

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

MK

[shat...@gmail.com]

прочитал ответы и чувствую что пришла пора читать документацию :)

[shat...@gmail.com]

И ещё.
Вот например - у меня есть модель, я хочу дописать к ней метод,
возвращающий мне набор экземпляров модели, и я знаю что этот метод
должен вернуть 2 объектa.
Я в spec файл для этой модели добавляю спецификацию
it "should return list" do
#добавляем заглушку
MyModel.stub!(:get_list).and_return([1,2])
#gроверяем количество объектов
MyModel.get_list.size.should == 2
end
Теперь, как я понял, я в модели пишу настоящий код метода get_list и в
спеке коментарю строку
MyModel.stub!(:get_list).and_return([1,2]), убирая заглушку. Так?

[Timur Vafin]

shat...@gmail.com пишет:

Ммм... Интересный конечно подход.

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

Т.е.:
* зафантазировал метод
* описал тест
* запустил тест, увидел ошибку
* написал метод
* запустил тест, увидел, что нет ошибки
* радоваться

http://blog.davidchelimsky.net/articles/2007/05/14/an-introduction-to-rspec-part-i

[liquidautumn]

не надо глушить, дай спеке возможность показать тебе undefined method,
что должно натолкнуть тебя на мысль этот метод определить :)
стабы и моки нужны чтобы заткнуть (в случае стабов) и
проконтролировать (в случае моков) вызов метода, который не относится
к спекируемому аспекту системы. Например во спеках вьюхи заглушить
вызов хелпера:
@controller.template.stub!(:ma_helpa).and_return('shite') вернет шит в
случае вызова заглушенного метода, но никак не отреагирует, если метод
вызван не будет.
@controller.template.should_receive(:ma_helpa).and_return('shite') же
добавляет expectation и если метод вызван не будет, expectation will
fail

[shat...@gmail.com]

Спасибо большое за ответы.
Просто я думал что спецификация - это описание как должно работать ещё
не написанное приложение.
И потом когда написанов спецификации что должны делать объеты -
реализуем код.
После реализации кода спецификации используються как тесты.
А так я пока честно говоря не увидел большой разницы от обычных
рельсовых тестов.

[Michael Klishin]

On 31.05.2007, at 14:30, shat...@gmail.com wrote:

> Спасибо большое за ответы.
> Просто я думал что спецификация - это
> описание как должно работать ещё
> не написанное приложение.
> И потом когда написанов
> спецификации что должны делать
> объеты -
> реализуем код.

Так и есть.

> После реализации кода спецификации
> используються как тесты.
> А так я пока честно говоря не увидел
> большой разницы от обычных
> рельсовых тестов.
>

А где написано, что должна быть большая?

MK

[shat...@gmail.com]

Просто несколькими постами выше меня заприкалывали что я стабы
использовал :)

[shat...@gmail.com]

В общем пока я дошёл до следующего -
например надо описать одну модель "Адреса"
в блоке before создаём псевдообъект с нужными стабами
ниже описываем кучу спецификаций
стабы нам позволяют прогнать всё без ошибок и мы увидим
Адрес
-должен делать это
-и это
-и погоду просчитывать
-и кофе варить

затем начинаем реализовывать методы и постепенно убираем стабы из
before
в итоге после написания всех методов у нас спецификация будет
выступать в роли тестов и проверит уже не стабы а реальные методы

Поругайте мои догадки пожалуйста кто как может, или согласитесь:)

[liquidautumn]

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

[shat...@gmail.com]

Так "в чём сила брат?" (с)
т.е. силв спеков что там можно написать "Модель должна выводить этим
методом такие числа", что ли? Это можнов текстовом файле написать.

[Serhiy Boiko]

Попробуй и поймешь.
В текстовом файле тоже можно. Это олдскул - так в ТДД предлагалось делать.
Классическая книга Кента Бека. Актуальная до сих пор.

В БДД ты объединяешь описание и тесты - таким образом нету разрыва между тем
что нужно сделать и чем это делаемое будет тестироваться.

Отличия от ТДД - акцент на проектирование плюс более удобно писать тесты из-за
того, что не нужно помнить порядок аргументов (у кого-то из наших перцев в
блоге почитал).

--
Serhiy Boiko
CRIS-UANIC

[liquidautumn]

В красивом dsl, в контекстах, в shared behaviours, в
самодокументированности, во многом.
Можно и в текстовом написать + тесты, а можно и без них обойтись.
Вопрос подхода :)

[shat...@gmail.com]

Ясно, всем спасибо за разъяснения - вот только венусь к началу
треда :) - никто не знает как одну спецификацию в спек файле
запустить? :)

[Michael Klishin]

-s, --spec SPECIFICATION_NAME Execute context or
specification with matching name
-l, --line LINE_NUMBER Execute context or
specification at given line

Волшебство можно найти либо в файле
options_parser.rb в репозитории, либо сделав
spec -h

Код, который запускает спеку, на
которой курсор, в TextMate:

def run_focused(stdout, options={})
options.merge!({:files => [single_file], :line => ENV
['TM_LINE_NUMBER']})
run(stdout, options)
end

def run(stdout, options)
argv = options[:files].dup
argv << '--format'
argv << 'Spec::Runner::Formatter::TextMateFormatter'
if options[:line]
argv << '--line'
argv << options[:line]
end
argv += ENV['TM_RSPEC_OPTS'].split(" ") if ENV['TM_RSPEC_OPTS']
Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) do
::Spec::Runner::CommandLine.run(argv, STDERR, stdout, false,
true)
end
end

Как видно, путь к цели именно тот самый

MK

[shat...@gmail.com]

пасиба

[Julian 'Julik' Tarkhanov]

On Jun 4, 2007, at 2:19 PM, liquidautumn wrote:

В красивом dsl, в контекстах, в shared behaviours, в

самодокументированности, во многом.

а несила имхо в том что too much magic

не доверяю я ему, во всяком случае пока он не встроенный в рельсы (то есть пока нет гарантии

что "оно заведется без бубна" - на бубны последнее время страшно не хватает времени)

-- 

Julian 'Julik' Tarkhanov

please send all personal mail to m...@julik.nl