Сначала надо тестами код покрыть, а потом рефакторить. И я не писал, что не понимаешь, что код делает — понимаешь конечно, просто какие-то ветвления, аспекты можешь упустить.
Вынос различных аспектов логики в разные классы оправдан также с точки зрения тестирования. Удобнее мокнуть класс-валидатор, чем private метод.
Оставляя всю логику в одном классе мы скатывается к процедурному стилю, о котором я писал в статье.
И очень наивно полагать, что логика будет использоваться только в одном месте. Вы упомянули функцию парсинга- так завтра появится новое требование, что для нового клиента парсинг отличается на пару символов, отсупов итд. и время — на имплементацию — час. В этом случае не будет времени ни на какой рефактонинг и прогматичный разработчик просто скопирует старый класс подправить пару строчек. Пожар потушен- но в долгосрочной перспективе- деградация кода.
Послушайте, друзья, идея статьи была не в том, что тестировать или не тестировать private методы/поля, а удобно ли это делать testprivates. Посмотрите хотя бы на https://github.com/dimpon/testprivate
Ну, наверно эта логика все-таки доступна через public метод. Но если очень хочется конечно можно тестировать, только не делать ее package-private, а то оглянуться не успеете как она будет не в одном месте вызывается.
Да к сожалению не всегда. Бывает надо изменить логику, а ты просто не можешь понять как это работает, потому что там 30 private и package-private методов, каждый в 3 экрана, которые друг друга вызывают. Вот и начинаешь разносить код, потому что всех кейсов проследить не можешь.
Добрый день! mmMike давайте по-порядку.
Насчет тестирования private методов есть разные мнения, и я как раз оправдываю ситуации когда их тестируют. Но ряд авторов считает, что так делать не надо www.infoq.com/news/2008/01/private-methods-tdd-design
Я считаю, что выставлять наружу детали реализации (package-private методы) это плохо. Это ухудшает readability. И эти методы рано или поздно начнут дергать не только из тестов. К сожалению, в моем текущем проекте (10-летний монолит без четкой архитектуры, разрабатывается 3-мя командами, нет code ownership) это стандартная практика.
reflection в одном случае это нормально. в сто одном — уже не очень. а еще каждый делает это по-своему. А представьте, что надо засетить 10 private полей через reflection и потом протестировать один public метод?
ClassC obj = new ClassC();
Field aField = ClassC.class.getDeclaredField("a");
aField.setAccessible(true);
aField.set(obj,42);
// и так 10 раз
а если потом прочитать их нужно? а еще NoSuchFieldException и IllegalAccessException ловить.
Идея статьи — не писать фреймворк, а использовать библиотеку testprivate и описывать доступ к private полям/методам через интерфейс. И делать это одинаково во всем проекте.
Вы делаете интерфейс прям в тесте, добавляее методы совпадающие по сигнатуре с private методами и getters/setters для private полей и как будто кастите свой объект к этому интерфейсу.
Добрый день! да, правы, я ж написал «Когда они ради этого убирают слово private у метода и метод становится package-private.». С тестирование private методов я начал чтобы разжечь дискуссию, конечно это opinion-based. Но ряд авторов считает, что так делать не надо. Основная идея, что класс поддерживает контракт, предоставляемый public методами, его и надо тестировать. А все остальное — внутренние детали.
вот например: www.infoq.com/news/2008/01/private-methods-tdd-design
и там длинное обсуждение.
Добрый день!
Ну во-первых модификатора пока нет, и неизвестно появится ли он. А во-вторых решение в частном случае занимает 7 строк, а в общем 22. Код читаемый и понятный, а совсем не «тягомотина». Существующий код приложения, которого иногда гигабайты, не меняется. Показать это и была цель статьи.
Сначала надо тестами код покрыть, а потом рефакторить. И я не писал, что не понимаешь, что код делает — понимаешь конечно, просто какие-то ветвления, аспекты можешь упустить.
Вынос различных аспектов логики в разные классы оправдан также с точки зрения тестирования. Удобнее мокнуть класс-валидатор, чем private метод.
Оставляя всю логику в одном классе мы скатывается к процедурному стилю, о котором я писал в статье.
И очень наивно полагать, что логика будет использоваться только в одном месте. Вы упомянули функцию парсинга- так завтра появится новое требование, что для нового клиента парсинг отличается на пару символов, отсупов итд. и время — на имплементацию — час. В этом случае не будет времени ни на какой рефактонинг и прогматичный разработчик просто скопирует старый класс подправить пару строчек. Пожар потушен- но в долгосрочной перспективе- деградация кода.
Послушайте, друзья, идея статьи была не в том, что тестировать или не тестировать private методы/поля, а удобно ли это делать testprivates. Посмотрите хотя бы на https://github.com/dimpon/testprivate
Ну, наверно эта логика все-таки доступна через public метод. Но если очень хочется конечно можно тестировать, только не делать ее package-private, а то оглянуться не успеете как она будет не в одном месте вызывается.
Насчет тестирования private методов есть разные мнения, и я как раз оправдываю ситуации когда их тестируют. Но ряд авторов считает, что так делать не надо www.infoq.com/news/2008/01/private-methods-tdd-design
Я считаю, что выставлять наружу детали реализации (package-private методы) это плохо. Это ухудшает readability. И эти методы рано или поздно начнут дергать не только из тестов. К сожалению, в моем текущем проекте (10-летний монолит без четкой архитектуры, разрабатывается 3-мя командами, нет code ownership) это стандартная практика.
reflection в одном случае это нормально. в сто одном — уже не очень. а еще каждый делает это по-своему. А представьте, что надо засетить 10 private полей через reflection и потом протестировать один public метод?
а если потом прочитать их нужно? а еще NoSuchFieldException и IllegalAccessException ловить.
Идея статьи — не писать фреймворк, а использовать библиотеку testprivate и описывать доступ к private полям/методам через интерфейс. И делать это одинаково во всем проекте.
Вы делаете интерфейс прям в тесте, добавляее методы совпадающие по сигнатуре с private методами и getters/setters для private полей и как будто кастите свой объект к этому интерфейсу.
вот например:
www.infoq.com/news/2008/01/private-methods-tdd-design
и там длинное обсуждение.
Ну во-первых модификатора пока нет, и неизвестно появится ли он. А во-вторых решение в частном случае занимает 7 строк, а в общем 22. Код читаемый и понятный, а совсем не «тягомотина». Существующий код приложения, которого иногда гигабайты, не меняется. Показать это и была цель статьи.