1.2.3

## Спецификации

Для управления процессом разработки в проекте Rubinius активно используются исполняемые спецификации в стиле TDD/BDD. Директория `spec` проекта не без умысла разделена на две части:

1. файлы в `spec/ruby` — описывают поведение традиционной реализации от Мацумото;
2. все остальные файлы в директории `spec` — описывают поведение Rubinius.

Спеки1 в `spec/ruby` — это копия RubySpec соответствующей ревизии. Они регулярно импортируются из проекта RubySpec, причем сбойные помечаются таким образом, что CI-процесс2 всегда имеет доступ к набору проверенных валидных спецификаций. Такой подход позволяет легко удостовериться, что изменения в коде Rubinius не ведут к регрессиям.

Документацию по проектированию и написанию спеков можно найти на сайте «RubySpec project».

Когда Вы станете писать для Rubinius спеки и соответствующий им код, соблюдайте следующий порядок:

1. Напишите «сбойный» спек для определенного поведения Ruby. Закоммитьте его в отдельный коммит в подходящем месте в `spec/ruby`.
2. Создайте код для Rubinius, при выполнении которого спек «пойдет». Затем снова закоммитьте: этот коммит должен быть отличным от первого, содержащего сам спек.
3. Запустите `rake`, чтобы убедиться, что все CI-спеки выполняются успешно.

Изменения в файлах дерева `spec/ruby` регулярно отправляются нами в RubySpec. В то же время свежие обновления, которые присылаются в RubySpec разработчиками других реализаций Ruby, регулярно вносятся в `spec/ruby`. Так же, соответственно обновлениям RubySpec, обновляются и теги в CI.

#### Примечания

1. Спек – от сокр. англ. «spec», спецификация.
2. CI – утилита системы непрерывной интеграции.