Новости информационных технологий - 25930

А чтобы тестировать не отходя от кассы нужен фреймворк который внедряется в код
но никак не влияет на его работу.
Именно это делает Spine — позволяет писать тесты рядом с кодом никак не влияя на работу приложения.

Почему Spine?
Потому что «Specs Inline» и потому что(imho) для рационального ПО, тесты играют роль позвоночника.

Многим это статья может показаться повтором и они будут отчасти правы,
так как данная статья основана на пятой части знакомства с Presto.
А сам Spine вырос из и стал на замену PrestoTest фреймворка.

И зачем повторять то что уже написано?
Просто Spine существенно отличается от PrestoTest и соответственно данная статья тоже отличается от предыдущей, процентов на 80.
Да и представлять новый гем в пятой части знакомства с Presto как-то не корректно.

И да, статья не претендует на большие плюсы. Если вам данная методология не по вкусу,
минусовать не зачем, просто игнорируйте её и используете ваш любимый тест-фреймворк. Спасибо.

Мотивация:

1. Визуальный контакт. Я хочу писать спецификации одновременно с кодом
   и чтобы они физически находились рядом, в том же файле или папке, но никак не в амбаре.
2. Простые вещи должны остаться простыми.
   foo.should == bar никак не заменит foo == bar
3. Я не хочу ни запоминать список синтетических заменителей простых вещей
   ни работать с документацией под рукой.
4. Никаких хаков. Тестируемые объекты и базовые классы Ruby должны остаться в
   первоначальном состоянии.

Читать полностью »