А чтобы тестировать не отходя от кассы нужен фреймворк который внедряется в код
но никак не влияет на его работу.
Именно это делает Spine — позволяет писать тесты рядом с кодом никак не влияя на работу приложения.
Почему Spine?
Потому что «Specs Inline» и потому что(imho) для рационального ПО, тесты играют роль позвоночника.
Многим это статья может показаться повтором и они будут отчасти правы,
так как данная статья основана на пятой части знакомства с Presto.
А сам Spine вырос из и стал на замену PrestoTest фреймворка.
И зачем повторять то что уже написано?
Просто Spine существенно отличается от PrestoTest и соответственно данная статья тоже отличается от предыдущей, процентов на 80.
Да и представлять новый гем в пятой части знакомства с Presto как-то не корректно.
И да, статья не претендует на большие плюсы. Если вам данная методология не по вкусу,
минусовать не зачем, просто игнорируйте её и используете ваш любимый тест-фреймворк. Спасибо.
Мотивация:
- Визуальный контакт. Я хочу писать спецификации одновременно с кодом
и чтобы они физически находились рядом, в том же файле или папке, но никак не в амбаре. - Простые вещи должны остаться простыми.
foo.should == barникак не заменитfoo == bar - Я не хочу ни запоминать список синтетических заменителей простых вещей
ни работать с документацией под рукой. - Никаких хаков. Тестируемые объекты и базовые классы Ruby должны остаться в
первоначальном состоянии.
.jpg "62 полезных инструмента для адаптивного дизайна (Responsive web design)")
