@pongo чтобы навигация по файлу и даже базовый Find&Replace в кошмар превратились? Какие ещё задачи это решает?
Top-level
@pongo чтобы навигация по файлу и даже базовый Find&Replace в кошмар превратились? Какие ещё задачи это решает? 6 comments
@pongo тестирование приватных методов это в принципе сомнительная практика, приватный метод - implementation detail, и тесты об их существовании вообще знать не очень должны. Кроме того, тесты часто занимают в разы больше места, чем реализация, особенно если это что-то BDD-подобное. В этом случае уместнее говорить о включении имплементации в файл с тестами. И вот ещё: в релизном билде эти тесты не нужны(как и тестовые импорты и зависимости), и нужно костылить их вырезание @zhulik у такого подхода есть и плюсы, и минусы; во многом дело вкуса. мне было интересно попробовать, но в рабочих проектах я это не буду использовать, по крайней мере пока что — слишком уж непривычно. зато мне показалось правильным располагать модульные тесты как можно ближе к исходному коду (т.е. в той же папке, а не в отдельной папке с тестами). @pongo "как можно ближе" довольно субъективная метрика. Переключение между имплементацией и тестами в другом файле и/или папке по хоткею это достаточно близко? Или это дальше чем скролл по одному файлу? Или ближе? @pongo тот же самый хоткей ее за тебя создаёт в rubymine+rspec. Для других редакторов/ide подобное тоже должно быть |
@zhulik упрощает тестирование приватных методов (не нужно их экспортировать). плюс, все тесты под рукой (а не где-то там)