Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
 Re: Тестирование private методов  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
mayton
Stanislav Bashkyrtsev
пропущено...
Я ничего не говорил про JMH и пр. Я не хочу сравнивать две реализации хеш таблиц, я хочу убедиться что свою хеш таблицу с external chaining'ом я реализовал правильно. Т.е. что сам алгоритм написан by the book. И это было бы легко сделать, если бы бакеты были доступны в тестах. Однако это нарушение инкапсуляции.

Я понял ваш месседж. Я просто добавлю что есть некое промышленное тестирование качества бизнес-логики
которому вполне достаточно протестировать чёрный ящик. Если ящика по каким-то причинам не достаточно
- то его выбрасывают и берут другой ящик или декомпозицию на несколько более мелких.

То о чем рассказываете вы насколько далекО от тестинга качества бизнес-логики что его можно просто выделить в одельную
категорию и отменить для нее законы ООП. В самом деле. Зачем вам ООП когда вы создаете свою структуру данных.
Вот создайте ее. Доработайте до конца. И после этого уже займитесь инкапсуляцией. Это будет в духе SingleResp/OpenClosed.

Вот такое вот IMHO.

На мой взгляд - пример Stanislav Bashkyrtsev как раз таки достаточно близок к реальному миру.

совет:
"Зачем вам ООП когда вы создаете свою структуру данных. Вот создайте ее. Доработайте до конца. И после этого уже займитесь инкапсуляцией."

На мой взгляд за гранью добра и зла. Не бывает програмного кода/структуры данных который один раз создали, заинкапсулировали и больше не дорабатывают/не трогают. Это даже не фантазии, а полный отрыв от реальности.

Зачем после разработки заниматься инкапсуляцией - я вообще не понимаю. Да и модификатор доступа private то же не очень, чем мешает в реальной жизни замена private на protected - мне не сильно понятно.

IMHO

p.s. Что такое "SingleResp/OpenClosed" не знаю, фразы не понял.
28 май 21, 14:31    [22328459]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
gmugar
Member

Откуда:
Сообщений: 23
Leonid Kudryavtsev
p.s. Что такое "SingleResp/OpenClosed" не знаю, фразы не понял.

single-responsibility principle
open–closed principle
28 май 21, 15:06    [22328489]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Спасибо. Да все верно.
28 май 21, 15:15    [22328499]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
gmugar
open–closed principle

"закрыты для изменения" на мой взгяд, совершенно плохое сочитание слов. Значения вкладываемое в open-closed сильно отличается от их обычное значение в русском языке и противоречит их восприятию с точки зрения инкапсуляции и/или областей видимости.

private метод, который мешает/усложняет тестирование порожденных классов, как раз open-closed и противоречит

IMHO
28 май 21, 15:27    [22328509]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
Leonid Kudryavtsev
gmugar
open–closed principle

"закрыты для изменения" на мой взгяд, совершенно плохое сочитание слов. Значения вкладываемое в open-closed сильно отличается от их обычное значение в русском языке и противоречит их восприятию с точки зрения инкапсуляции и/или областей видимости.

private метод, который мешает/усложняет тестирование порожденных классов, как раз open-closed и противоречит
OCP - это когда для изменения поведения мы не лезем менять существующий код. Например, создаем новую сущность как в случае Decorator/Proxy. Или передаем Command/Strategy в класс вместо того чтоб прям в нем описывать разные стратегии поведения.

Сообщение было отредактировано: 28 май 21, 15:32
28 май 21, 15:40    [22328519]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Leonid Kudryavtsev

private метод, который мешает/усложняет тестирование порожденных классов, как раз open-closed и противоречит

IMHO

Нужно на конкретном примере рассмотреть. Мне кажется - что если приватный метод имеет смысл только
в контксте базового класса (хелпер, утилита) то нет смысла делать его protected т.к. его тело будет уже
мешать производному классу.

Впрочем, это философия. Весь SOLID - философия.
28 май 21, 16:11    [22328545]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
da17
Member

Откуда:
Сообщений: 448
Если что, то я уже все уяснил. А вот мне еще хотелось бы уточнить у более опытных коллег, теперь для тестирования часто приходится переделывать интерфейсы классов. Например был класс B который использовался в классе A и нигде более. Что бы протестировать поведение класса А пришлось B выносить наружу и передавать в конструктор, иначе не сделаешь его мок-объектом. Как-то вот странно все это.

Сообщение было отредактировано: 28 май 21, 18:05
28 май 21, 18:12    [22328597]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
andreykaT

так тестируй публичный метод который эти прайваты использует. или ты хочешь тестировать прайват методы в классе где никаких других кроме прайватов нет? :) и конструктар тоже прайват?


не все так однозначно- например паблик метод который дергает пару десятков мапперов и тд,которые приватны.
А если все это еще и в асинхрощине .
понятно что если отдать на вход а и получить то что ты хотел- оно хорошо и правильно ,значит все внутри работает,но бывает так что какой то хороший человек меняет что то в коде,сборщик падает с красным тестом- а там метод,который я описал выше и сразу не очень понятно что поломал этот человек- что по сути не есть хорошо - вот поэтому лучше сделать желаемые для тестов методы пекейдж приватными и тестировать сколько душе угодно.
Разраб же он какой- хочет на каждый баг по 4 часа из спринта- вникнуть в контекст,подебажить и тд- а тут куча мелких тестиков и сразу видно - ну вот же тут не тот тип данных или что то еще)
а если включиться в вашу философию то можно написать один тест на весь сервис ага работает ну и хрен с ним тогда)
28 май 21, 19:03    [22328630]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
da17
Если что, то я уже все уяснил. А вот мне еще хотелось бы уточнить у более опытных коллег, теперь для тестирования часто приходится переделывать интерфейсы классов. Например был класс B который использовался в классе A и нигде более. Что бы протестировать поведение класса А пришлось B выносить наружу и передавать в конструктор, иначе не сделаешь его мок-объектом. Как-то вот странно все это.
Используй здравый смысл. Вот мы несколько постов подряд и обсуждали как раз этот момент - что вроде как тесты хочется написать на что-то скрытое внутри, но при этом это скрытое не хочется открывать. И как видишь однозначного ответа здесь нет.
28 май 21, 20:14    [22328662]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
da17
Если что, то я уже все уяснил. А вот мне еще хотелось бы уточнить у более опытных коллег, теперь для тестирования часто приходится переделывать интерфейсы классов. Например был класс B который использовался в классе A и нигде более. Что бы протестировать поведение класса А пришлось B выносить наружу и передавать в конструктор, иначе не сделаешь его мок-объектом. Как-то вот странно все это.


Дык понятно странно.
Т.к. "по правильному" нужно в начале писать unit-test, а потом делать реализацию.
Наоборот получается дико не удобно.

В таком случае, лучше "забить" на unit-test.

А написать интеграционный тест, который тестирует часть бизнес-логики.
И мокать в лучшем случае работу с БД (ну или другим хранилищем данных).

Тестировать всю цепочку объектов.

При этом не надо стремиться к 100% покрытию тестами.
Только success-варианты.

Остальное валить в Exception.
31 май 21, 08:04    [22329098]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
mad_nazgul, эм.. вообще результат не должен зависеть от того как ты к нему пришел. Кто-то использует TDD, кто-то нет, но количество и качество тестов не должно зависеть от этого.

TDD в некоторых случаях ускоряет написание prod кода. Кто-то им не пользуется и возможно в некоторых ситуациях пишет prod код медленней, соответственно это минус один бонус. Но остальные бонусы тестов (как модульных, так и других) остаются актуальными.

Сообщение было отредактировано: 31 май 21, 10:45
31 май 21, 10:53    [22329179]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
Stanislav Bashkyrtsev
mad_nazgul, эм.. вообще результат не должен зависеть от того как ты к нему пришел. Кто-то использует TDD, кто-то нет, но количество и качество тестов не должно зависеть от этого.

TDD в некоторых случаях ускоряет написание prod кода. Кто-то им не пользуется и возможно в некоторых ситуациях пишет prod код медленней, соответственно это минус один бонус. Но остальные бонусы тестов (как модульных, так и других) остаются актуальными.


Так он и не зависит.
Просто unit-tests без TDD - это одна сплошная головная боль.
Как бы только от этого не много.
31 май 21, 15:42    [22329396]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
gmugar
Member

Откуда:
Сообщений: 23
Stanislav Bashkyrtsev
Я ждал когда будет предложен этот вариант. Ведь именно он якобы решает все проблемы: и тестировать проще, и инкапсуляцию можем соблюдать. Но:
1. Если этот доп класс будет public, то тут два варианта:
1.а Мы его предаем в конструктор тому кто создает CSV. В таком случае мы усложнили клиентский код. Т.е. ради тестов мы усложнили прод код.
1.б Мы его создаем внутри класса который в итоге генерит CSV. И если мы их тестируем отдельно, то мы предполагаем что CSV класс использует класс вычислениями и тем самым опять же нарушаем инкапсуляцию.
2. Если этот доп класс будет package private, то:
2.а Мы все равно тестируем не Public API. Т.е. по сути это то же самое что тестировать не public метод.
2.б То же что и в 1.б

я бы сделал примерно так:
1. новый публичный метод(e.g. getResults()), который возвращает результаты в виде какой-то удобной (и unmodifiable) структуры,
(ничего плохого а таком методе нет: он не раскрывает никаких кишок класса; по сути, это те же данные, которые клиенты уже получают посредством toCsv(), просто в другом формате )
2. новый класс (e.g. CSVWriter), для генерации CSV, который получает эту новую структуру, в конструктор (или параметр метода, не суть)
3. меняем метод toCsv(): он теперь использует новый класс (e.g. new CSVWriter(this.getResults()).write() )
что получилось:
1. новый метод дает нам данные в удобной для тестирования форме
2. новый класс (e.g. CSVWriter) даже не надо тестировать: он будет протестирован уже существующими тестами для toCsv()
3. никакого изменения сложности для клиентов не произошло; для них вообще ничего не поменялось
4. все гораздо лучше с точки зрения single-responsibility principle
5. приоткрыта дверца в сторону поддержки других форматов вывода

это конечно далеко от идеала, но даже так, сильно лучше чем было. IMHO

Stanislav Bashkyrtsev
Не верь всему что пишут на заборах.

вот зря вы так.
Robert Martin написал несколько хороших книжек и ввел в обиход понятие Clean Code.
да, не все что он пропагандирует бесспорно, но, в целом, он говорит правильные вещи
1 июн 21, 14:43    [22329855]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
gmugar
новый публичный метод(e.g. getResults()), который возвращает результаты в виде какой-то удобной (и unmodifiable) структуры,
Ну вот ты открыл метод который до этого был private или package private (если мы его таки открывали для тестирования). Что здесь принципиально поменялось? Т.е. если этот метод лежал в старом классе, то тебе не нравилось его открывать только для тестирования. А если его перенести в другой класс и сделать public, то так открывать код чисто для тестирования - правильно. Почему?
gmugar
он не раскрывает никаких кишок класса; по сути, это те же данные, которые клиенты уже получают посредством toCsv(), просто в другом формате
Плохо тут то что у нас +1 публичная сущность. До этого я видел с какими классами в пакете мне нужно было взаимодействовать, а теперь оказывается есть public классы которые на самом деле мне не нужны. Но эта проблема решается - твой новый класс можно сам по себе сделать package private, т.е. он не будет виден из-вне пакета. Но опять же - в чем разница метод открывать или класс?
gmugar
Robert Martin написал несколько хороших книжек и ввел в обиход понятие Clean Code.
Я не большой знаток Дяди Боба, все что я о нем знаю:
1. Он написал книгу на простую тему: Clean Code. Ее в общем-то много кто мог написать. Хотя это все равно полезная работа. Если бы он только по-аккуратней писал про комментирование кода.. а то многие ленивые жопы теперь не заставить документацию писать.
2. Он создал Fitnesse - самый ужасный из известных мне фреймворков для тестирования.

Наверняка он еще что-то сделал, о чем я не знаю.. Но тем не менее, полагаться на авторитет неправильно - каждую идею нужно понимать и рассказывать от себя. А не просто ссылаться на великие умы.
1 июн 21, 15:24    [22329886]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
mad_nazgul


Так он и не зависит.
Просто unit-tests без TDD - это одна сплошная головная боль.
Как бы только от этого не много.


юнит тесты это хорошая и правильная штука,а TDD для тех ,кто какает в себя
1 июн 21, 19:12    [22330045]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
asv79
mad_nazgul


Так он и не зависит.
Просто unit-tests без TDD - это одна сплошная головная боль.
Как бы только от этого не много.


юнит тесты это хорошая и правильная штука,а TDD для тех ,кто какает в себя


Автоматические тесты это хорошая и правильная штука.
unit-test это инструмент для разработчика.
Им можно пользоваться, можно не пользоваться.
unit-test без TDD это головная боль, что показал ТС. :-)
2 июн 21, 06:38    [22330152]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Техника TDD не везде подходит. Если у вас - прототип или какой-то быстро развивающийся стартап
то TDD никто не пишет просто по причине отсуствия контрактов. Их - некому описать. Поэтому
иногда лошадь бежит впереди телеги и иногда телега бежит впереди.
2 июн 21, 10:55    [22330202]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
mayton
Техника TDD не везде подходит. Если у вас - прототип или какой-то быстро развивающийся стартап
то TDD никто не пишет просто по причине отсуствия контрактов. Их - некому описать. Поэтому
иногда лошадь бежит впереди телеги и иногда телега бежит впереди.


Все равно когда пишешь код, какой-то контракт появляется, так что стартап это не помеха использованию TDD.
TDD как раз позволят итеративно создавать и уточнять контракт.
Просто техника TDD настолько не привычная, что для использования нужно ломать свои навыки разработки об колено.
При этом преимуществ для того кто пишет не так уж и много.
2 июн 21, 16:17    [22330439]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3852
mad_nazgul
Просто unit-tests без TDD - это одна сплошная головная боль.


если сходить в армию, то там довольно быстро объяснят кое-какие "постулаты":
- нужно знать устав
- соблюдать субординацию
- все должно быть параллельно или перпендикулярно

TTD - это из той же оперы: лысый черт собрал себе армию поклонников и эти поклонники носятся с TTD как дураки с писаной торбой, хотя на качество кода TTD вообще никак не влияет:
- если задаться вопросом получился ли в итоге хороший дизайн или нет - это выясняется только после того как API начали пользоваться третьи лица, а то что тесты под него написаны - это не суть важно, вон все API связанное к криптографией выглядит откровенно так себе (я еще какой-нить ASN.1 не упоминаю), однако его кто-таки в жаву затащил (оно же тесты проходит, ага)
- большинство проектов состоит из библиотечных вызовов чуть более чем полностью, на кой лад пытаться смотреть на метрики jacoco, если оно краевые эффекты в библиотеках не покрывает? нужно следить за тем, чтобы тесты были сами по себе разумные и затрагивали библиотеки
2 июн 21, 16:19    [22330443]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
mad_nazgul

Все равно когда пишешь код, какой-то контракт появляется, так что стартап это не помеха использованию TDD.

Сложно... сложно все это. Если говорить о контракте на "кончиках пальцев", то пишущий его не успеет
описать даже словами. Стартап - это бешеный темп продуцирования кода, 90% из которого завтра
уйдет в мусорное ведро. А пишуший - суть вольный художник который "так видит" или просто делает
POC или демо возможностей. Он слишком увлечен идеей чтобы ее формализовывать. Попробуйте ввести
в стартапы стандартные процессы - и стартап умрёт и кодеры разбегуся в разные стороны.

IMHO.
2 июн 21, 18:03    [22330504]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
mayton
mad_nazgul

Все равно когда пишешь код, какой-то контракт появляется, так что стартап это не помеха использованию TDD.

Сложно... сложно все это. Если говорить о контракте на "кончиках пальцев", то пишущий его не успеет
описать даже словами. Стартап - это бешеный темп продуцирования кода, 90% из которого завтра
уйдет в мусорное ведро. А пишуший - суть вольный художник который "так видит" или просто делает
POC или демо возможностей. Он слишком увлечен идеей чтобы ее формализовывать. Попробуйте ввести
в стартапы стандартные процессы - и стартап умрёт и кодеры разбегуся в разные стороны.

IMHO.

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

TDD наверно хорош там где у тебя все описано и задокументировано,на разраба присылают чотко описанные задачи,вплоть до типа и размера полей.Тут можно написать тест и потом к нему код,потому что изменений не будет- все описано и согласовано - а коддер тут по сути как обычный наборщик текста,поэтому без разницы что сначала писать код или тест
2 июн 21, 19:38    [22330557]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
Андрей Панфилов
на качество кода TTD вообще никак не влияет:
- если задаться вопросом получился ли в итоге хороший дизайн или нет - это выясняется только после того как API начали пользоваться третьи лица, а то что тесты под него написаны - это не суть важно, вон все API связанное к криптографией выглядит откровенно так себе (я еще какой-нить ASN.1 не упоминаю), однако его кто-таки в жаву затащил (оно же тесты проходит, ага)
- большинство проектов состоит из библиотечных вызовов чуть более чем полностью, на кой лад пытаться смотреть на метрики jacoco, если оно краевые эффекты в библиотеках не покрывает? нужно следить за тем, чтобы тесты были сами по себе разумные и затрагивали библиотеки
Я хоть и согласен с посылом что TDD не улучшает дизайн, но аргументов этих все равно не понимаю.. Причем тут jacoco к TDD, как криптография к TDD относится.. Известно что Java реализацию писали следуя TDD? Че-т сомневаюсь. То что там тесты написаны - не говорит о том как их писали. Да и криптография - это странный пример в целом, в ней многое сделано некрасиво:
а) потому что требуется хорошая производительность
б) потому что пишут security эксперты, а не программисты которые умеют писать
И уж тем более не понимаю причем тут ASN.1.. Это просто формат, это как говорить что XSD/XML некрасивые, к TDD - никакого отношения.
mayton
Стартап - это бешеный темп продуцирования кода, 90% из которого завтра
уйдет в мусорное ведро.
Ну во-первых, здесь описан как раз очень медленный темп (потому как 90% в мусор), а во-вторых.. Тут многие пишут про мифические стартапы, но такое ощущение что не совсем понимают что это. Стартап - это просто проект, который получил огромное финансирование еще на этапе идеи/прототипа/ранней версии (поэтому он start up). Это не гарантирует что там какой-то страшно быстрый темп и что все пишут говнокод на коленке. Наверно большинство стартапов правда разрабатываются в быстром темпе, как собственно и обычные проекты. Часто слышу что больше 90% стартапов проваливаются - возможно от части это из-за быстрого темпа.. Может даже из-за отсутствия TDD (шучу).
asv79
я работаю в конторе,которая очень активно развивается и мы пишем очень много кода,зачастую я начинаю какой то модуль - и еще толком никто не знает как должно быть вообще,есть некая бизнес хотелка,по которой бегло пробежались аналитики и все -я просто не представляю ,как на такое накинуть TDD
Ну это лишь значит что у вас слабые аналитика, разработка и, видимо, в целом процессы. У вас в принципе мало шансов на эффективную разработку. Это не значит что у вас ничего не получится, это лишь значит что вы медленно продвигаетесь вперед.

Основная задача TDD лишь в том, чтоб разбивать сложные задачи/алгоритмы на мелкие шаги. Сложные штуки бывают во всех отраслях и во всех типах организаций. И в "активно развивающихся", и в стабильных.

Сообщение было отредактировано: 2 июн 21, 21:14
2 июн 21, 21:21    [22330595]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11020
mayton
стартап умрёт и кодеры разбегуся в разные стороны.
Так может это и к лучшему?
3 июн 21, 06:24    [22330698]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Может быть и к лучшему.
3 июн 21, 10:00    [22330749]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Stanislav Bashkyrtsev
Часто слышу что больше 90% стартапов проваливаются - возможно от части это из-за быстрого темпа.. Может даже из-за отсутствия TDD (шучу).

Разумеется TDD здесь не причем. Правильнее сказать что TDD не влияет на принятие решения о качестве
стартапа. Ведь стартап демонстрирует идею или концепт. И временные затраты на TDD не дают того ощутимого
результата в данном случае. А оттачиванеи качества кода - это уже 2 фаза стартапа. Когда уже бизнес заинтересован
в продолжении эксплуатации этого изделия. Здесь уже можно и баги закрыть или качество покрытия поднять.
Поэтому лошадь и телега поменялись местами.

IMHO

Сообщение было отредактировано: 3 июн 21, 11:04
3 июн 21, 11:05    [22330792]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Java Ответить