NT
Ладно, а теперь вопрос в тему - что сейчас лучше почитать про то, как писать тесты на r spec? То есть с нуля и до полноценного покрытия? "Штатный" manual для рельсов мне настолько не зашёл, видимо я не понимаю концепции
Size: a a a
2020 September 11
AD
Ладно, а теперь вопрос в тему - что сейчас лучше почитать про то, как писать тесты на r spec? То есть с нуля и до полноценного покрытия? "Штатный" manual для рельсов мне настолько не зашёл, видимо я не понимаю концепции
книжка была от Pragmatic Programmer
FK
Ладно, а теперь вопрос в тему - что сейчас лучше почитать про то, как писать тесты на r spec? То есть с нуля и до полноценного покрытия? "Штатный" manual для рельсов мне настолько не зашёл, видимо я не понимаю концепции
Aaron Summer "Everyday rails testing"
NT
Хм, спасибо
k
основная фишка тестов - помочь себе будущему
NT
Штука в том, что у меня написан достаточно сложный проект панели управления сервисами хостинга - почта - DNS - web site (one site one docker container), осталось добить учётной системой счета/платежи
NT
Но вот из-за отсутствия тестов мне как то не хочется открывать код, что-ли
NT
Потому что я и сам сейчас после перерыва в разработке потерял контекст
2020 September 12
AI
Потому что я и сам сейчас после перерыва в разработке потерял контекст
Ну в принципе это одна из причин для чего пишут понятные тесты
NT
М? Видимо я не очень понимаю суть, да. Потому что вот допустим, у меня есть клиент, у него есть контакт, у клиента есть например, тарифный план, в котором есть два сайта с почтой, какими то почтовыми ящиками в домене..
NT
Как всю эту архитектуру тестировать
NT
Ну, то есть кусочками я понимаю, что если в тарифном плане может быть только два почтовых ящика, мы тестируем чтобы на третий пошёл отказ, и кнопочку добавить - заблокировать..
AI
М? Видимо я не очень понимаю суть, да. Потому что вот допустим, у меня есть клиент, у него есть контакт, у клиента есть например, тарифный план, в котором есть два сайта с почтой, какими то почтовыми ящиками в домене..
Тесты разных типов бывают, если тупо то можно разбить на интеграционные и юниты
AI
Юниты поидее сугубо один класс тестируют, интеграционные тестируют какой то кусок системы
AI
Какого то супер правильного подхода для интеграционных я не видел, пишутся по опыту и знанию системы
AI
Суть в том чтобы постараться побольше чистой логики держать которую юнитами легко тестировать
AI
Остальное интеграционными.
AI
Плюс часто тестируют через браузер, там просто накидываешь сценарии по своему усмотрению
NT
То есть, клиент создаётся и требования полей - один тест, что у клиента должен быть контакт, второй, что тарифный план можно привязать к клиенту только один - это ещё один..
AI
То есть, клиент создаётся и требования полей - один тест, что у клиента должен быть контакт, второй, что тарифный план можно привязать к клиенту только один - это ещё один..
Лучше стараться бизнеслогику юнитами тестировать