очевидно, раз поставили задачу научиться работать с методами разного уровня доступа, это не просто так :)

ну тогда вызывайте через send

и сразу говорите, что если увидете такое в коде, то найдете исполнителя и сломаете ему руку

главное, смотрите при этом прямо в глаза интервьюеру что бы поверил

у меня не тот уровень компетентности, чтоб калечить людей из-за автотестов)

для приватного метода? что?

Вообще за тесты приватных методов и их вызовы вне классов надо ссать на клаву

Вообще за тесты приватных методов и их вызовы вне классов надо ссать на клаву

ссать на клаву надо если тесты километровые

а что делать, если они исполняются 40 минут?

test-prof

и вперёд

а что делать, если они исполняются 40 минут?

паралелить

не, это то понятно

с клавой что делать положено в этом случае?

ссать

это неправильно

это неправильно

а как правильно ссать на клаву?

зайдет техлид в комнату, увидит процесс, и не сможет понять, в чем причина

на разные проблемы надо производить разные действия

?

и кстати чем плохо тестирование приватных методов? если у класса только один публичный метод и 10 приватных. то проще узнать какой из этих 10 сломался, если их тестить отдельно

да, но при этом буличный тоже надо протестить, и в итоге приватные ты протестишь дважды

а это удвоение времени выполнения каждый вызов рспека

какое-то время ничего страшного, а потом, тесты уже в 10 потоков выполняются полдня

и кстати чем плохо тестирование приватных методов? если у класса только один публичный метод и 10 приватных. то проще узнать какой из этих 10 сломался, если их тестить отдельно

Тестирование приватных методов плохо тем, что нарушает постулаты инкапсуляции. И фокусируется на реализации объекта а не на его поведении. Что в дальйшем аукнится при увеличени количества объектов.

ИМХО тесты немного вне теории программирования

приватные проще тестить на эдж кейсы. иначе будет сложно отловить все ситауции если будешь тестить только публичный. ну или же написать на публичный 10*х тестов, чтобы покрыть все приватные

в идеальном мире я бы покрывал тестами все вдоль и поперек, наплевав и на инкапсуляцию и на DRY и на все вообще

ну или тестить приватные, а при тесте публичного все их застабить )

про это Sandi Metz целую книжку написала. Там все очень прозрачно и читаемо.

Ну так тесть публичный и смотри покрытие

Лучше уж 10х тестов публичного написать чем приватные тестить

Зачем их тестировать вне контекста их вызова?

Потому что не факт, что ты покроешь все кейсы приватного

Я считаю, что лучше когда тестами покрыто всё, что имеет смысл тестировать

такой вопрос: есть параметр, у которого attr_writer публичный, а attr_reader protected. этот параметр участвует в другом наследуемом классе в вычислениях (суммируется с другим параметром). при запуске появляется ошибка +': nil can't be coerced into Integer (TypeError) это связано с тем, что attr_reader protected? как исправить?

Тестирование приватных методов плохо тем, что нарушает постулаты инкапсуляции. И фокусируется на реализации объекта а не на его поведении. Что в дальйшем аукнится при увеличени количества объектов.

Огромный плюс к этому

Тестировать приватные методы если и надо, то в исключительных случаях

в идеальном мире я бы покрывал тестами все вдоль и поперек, наплевав и на инкапсуляцию и на DRY и на все вообще

И потом при любом изменении ебался бы с прошлыми тестами на реализацию

Тестировать приватные методы если и надо, то в исключительных случаях

Смотря что он делает

И потом при любом изменении ебался бы с прошлыми тестами на реализацию

Антон скидывал статью, антипаттерны тестирования, и там про такое было

приватные проще тестить на эдж кейсы. иначе будет сложно отловить все ситауции если будешь тестить только публичный. ну или же написать на публичный 10*х тестов, чтобы покрыть все приватные

Если сложно тестить публичный то возможно у тебя слишком толстые классы

Смотря что он делает

Ну я просто по этому поводу не пришел к однозначному мнению, но имхо приватные методы надо тестировать в качестве исключения, если тестировать вовсе

Ну я просто по этому поводу не пришел к однозначному мнению, но имхо приватные методы надо тестировать в качестве исключения, если тестировать вовсе

Если там сложная логика или есть разные кейсы, то я считаю что нужно

Хотя не, надо избегать тестирования приватных методов вообще. Смотреть на стейт полей класса - куда ни шло, но тоже не оч кошерно

А что касается "не тестировать реализацию", то это не только к приватным относится Бывает что и публичный нет смысла тестировать отдельно

Practical Object Oriented Design in Ruby, An Agilie Primer (c) Sendi Metz

Если там сложная логика или есть разные кейсы, то я считаю что нужно

Сложная логика - сложный класс. Упрощай значит

Сложная логика - сложный класс. Упрощай значит

Философия мамкиных комментаторов )

Тут все умные гуру лучших практик

Философия мамкиных комментаторов )

S.O.L.I.D

А кодим мы на реальных проектах, которые кто-то делал до нас

Философия мамкиных комментаторов )

Ну можешь думать что хочешь по этому поводу

S.O.L.I.D

В рельсах солид польностью не соблюдается

Это опять же о комментаторах и их лучшим практиках, которые часто только в комментариях и существуют

А кодим мы на реальных проектах, которые кто-то делал до нас

И что?

Философия мамкиных комментаторов )

Зря вот так вот. Не надо так писать, это устраивать ругань.

Это не говорит о неверности моего суждения

Зря вот так вот. Не надо так писать, это устраивать ругань.

Тебе к Каролине )

Тебе к Каролине )

Дружище, не надо залупаться. И искать ссоры. Залупился на Тима, теперь на меня. Прекращай. Веди себя уважительно.

Обиженный? ?

ERROR: S client not available

Это опять же о комментаторах и их лучшим практиках, которые часто только в комментариях и существуют

Тут аргумент в стиле «а вот в реальности...». Предлагаю самостоятельно рассмотреть вопрос несостоятельности такой аргументации

Обиженный? ?

Еще раз и в бан.

Ахаха

Тестирование приватных методов плохо тем, что нарушает постулаты инкапсуляции. И фокусируется на реализации объекта а не на его поведении. Что в дальйшем аукнится при увеличени количества объектов.

а ты точно знаешь что такое юнит тесты?

а ты точно знаешь что такое юнит тесты?

не точно.

не точно.

короч у тебя будут километровые тесты

но я точно знаю что такое OOD

при black box

короч у тебя будут километровые тесты

нет.

нет.

что нет? ))))))

что нет? ))))))

Твое утверждение ложно.

Твое утверждение ложно.

подтверди чем нибудь пожалуйста

подтверди чем нибудь пожалуйста

не хочу.

потому что когда ты тестируешь black box чуть более чем простую логику - тебе придется кучу данных запилить чтобы протестировать внутренний приватный метод

контроллеры тестил когданить?

вот у тебя и будут километровые тесты на 4 страницы лишь бы не "ломать инкапсуляцию"

вот у тебя и будут километровые тесты на 4 страницы лишь бы не "ломать инкапсуляцию"

дело в том, что на эту тему есть видео выступление Sandi Metz где она детально разберает этот вопрос.

могу скинуть для ознакомления.

в 4 раз.

дело в том, что на эту тему есть видео выступление Sandi Metz где она детально разберает этот вопрос.

дело в том что всегда можно дать краткую выжимку

код с прода я тебе кидать конечно же не буду

а ты точно знаешь что такое юнит тесты?

Define юнит тесты Define интеграционные тесты

Define юнит тесты Define интеграционные тесты

я не спец но в моем понимании: (грубо) конкретный класс/метод в полной изоляции - юнит тест обращение к куску системы без моков - интеграционный тест

Ну тогда контроллеры больше подходят ко второй категории?

а так и есть

Типа тестишь апи своё

Условно

в общем то так и есть

Ну так это не юнит тесты, че тролешь

всмысле