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

Откуда:
Сообщений: 448
Добрый день, подскажите, если у класса есть private метод, как его можно протестировать при помощи JUnit. Можно наверное его сделать public, состояние класса он не меняет и ничего страшного, но вот нигде кроме этого класса этот метод не нужен и хочется как-то иначе.
21 май 21, 12:17    [22325219]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
kolchanov
Member

Откуда: Питер
Сообщений: 202
Если кратко - не надо тестировать private методы.

Подробнее написано в куче мест, например:
https://anthonysciamanna.com/2016/02/14/should-private-methods-be-tested.html
21 май 21, 12:28    [22325224]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
Но если все-таки захочется открыть метод, то его не обязательно делать public. Он может остаться package private ибо тесты обычно помещаются в тот же пакет что и тестируемые классы.

Ну еще есть вариант Reflection конечно, но выглядеть такой тест будет так себе :)

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

Откуда: loopback
Сообщений: 51389
Конечно не надо тестировать private-методы. Если вы - owner кода - то сделайте его хотя-бы видимым
в области пакета.

Если код не ваш и чужой то тем более не стоит тестировать. Его владалец может в новой версии удалить этот
метод и что вы будете с этим фактом делать.

Я думаю что тема технически перекликается с модульностью (java9-modules) и обсуждать ее надо именно
в таком ключе. Не ломать и хачить приватное, а разбираться почему вообще этот метод приватный и что за
функционал от него нам понадобилось тестировать, и компетентны ли МЫ вообще брать информацию из
чего-то внутреннего и закрытого от спецификаций.
21 май 21, 16:22    [22325372]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
если хочешь тестировать private методы- самое верное решение сделать из package private
то есть в сигнатуре метода просто убрать модификатор доступа
далее просто сгенерировать тесты на нужный класс- автоматом создаться пакет - в котором эти методы будут видны
ну и извне эти методы не буду видны,как и private- тоесть безопасность не пострадает
22 май 21, 19:40    [22325745]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
mayton
Конечно не надо тестировать private-методы.

тут ты не прав- по факту все методы в коде private- кроме тех,что торчат на контроллерах- и все это нужно тестировать
поэтому такие ситуации обыгрываются как package-private
а тестировать надо обязательно иначе на прод будет уезжать то,чего вы не ждали
22 май 21, 19:48    [22325748]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
asv79
mayton
Конечно не надо тестировать private-методы.

тут ты не прав- по факту все методы в коде private- кроме тех,что торчат на контроллерах- и все это нужно тестировать
поэтому такие ситуации обыгрываются как package-private
а тестировать надо обязательно иначе на прод будет уезжать то,чего вы не ждали

Приведи пример кода где тебе очень-очень нужно тестировать что-то приватное.
22 май 21, 20:21    [22325757]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
mayton,
легко- те же самые маперы
22 май 21, 22:00    [22325769]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Все равно непонятно.
22 май 21, 23:47    [22325783]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
da17
Member

Откуда:
Сообщений: 448
Вот решил попробовать Junit 5 и там уже кстати вроде разрешили тестить private методы. Хотя на своем примеры сам натолкнулся на то, что это не ОК, когда передал на вход ф-ии некорректные данные.
26 май 21, 12:18    [22327359]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Должен быть принцип тестирования ящика. Подал а вход что-то. Проверил на выходе нечто.

А если тебе надо взломать ящик - то тут... вроде как декомпозиция была сделана неверно.
Тоесть тут уже либо SingleResp/OpenClosed либо взламывай private но тогда не жалуйся
что плохое ООП.

Абсурд получается. С одной стороны на каждом собесе тебя спросят зачем нужно сокрытие
и с другой стороны ты сам-же пытаешся его нарушить в тестах. А тесты - это иммитация
эксплуатации системы.
26 май 21, 12:29    [22327372]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 8254
da17,
Дай пример метода и пример кода.
Ведь он никому больше в ИС не нужен кроме этого класса?
26 май 21, 12:48    [22327387]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
da17
Member

Откуда:
Сообщений: 448
PetroNotC Sharp, а я подумал и понял идею о том, что не надо тестировать private методы. Если еще смогу придумать зачем это надо, пока все понял.
26 май 21, 12:54    [22327393]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
andreykaT
Member

Откуда: =||==
Сообщений: 3402
mayton
asv79
пропущено...

тут ты не прав- по факту все методы в коде private- кроме тех,что торчат на контроллерах- и все это нужно тестировать
поэтому такие ситуации обыгрываются как package-private
а тестировать надо обязательно иначе на прод будет уезжать то,чего вы не ждали

Приведи пример кода где тебе очень-очень нужно тестировать что-то приватное.

имхо если хочется приватное что то тестировать то мне в скале нравится подход с хелпер объектами. ну или в джавке - статические методы в классе который не инстанциируется. оч круто.

я иногда так делаю и основной класс чище получается и потестить что то этакое можно. опять же оставляем хотя бы пакадж прайват.
26 май 21, 16:40    [22327560]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
andreykaT
Member

Откуда: =||==
Сообщений: 3402
asv79
mayton
Конечно не надо тестировать private-методы.

тут ты не прав- по факту все методы в коде private- кроме тех,что торчат на контроллерах- и все это нужно тестировать
поэтому такие ситуации обыгрываются как package-private
а тестировать надо обязательно иначе на прод будет уезжать то,чего вы не ждали

так тестируй публичный метод который эти прайваты использует. или ты хочешь тестировать прайват методы в классе где никаких других кроме прайватов нет? :) и конструктар тоже прайват?
26 май 21, 16:41    [22327562]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
gmugar
Member

Откуда:
Сообщений: 23
da17
PetroNotC Sharp, а я подумал и понял идею о том, что не надо тестировать private методы. Если еще смогу придумать зачем это надо, пока все понял.

Это ни зачем и никогда не надо.
Eсли класс нельзя на 100% покрыть тестами через его не приватный интерфейс - у тебя плохой дизайн класса. всегда. без исключений.
Cледствия:
1. если без PowerMock никак, то что не так
2. если в классе надо ослаблять видимость (например с private на package-private) только ради тестирования, то что-то не так
3. да, именно поэтому, Dependency Injection всегда и только - через конструктор
4. да, именно поэтому, private @PostConstruct/@PostLoad и т.п. - отвратительный anti-pattern которого надо избегать любой ценой
5. вообще любой вид инъекции в приватные поля и или методы - фу таким быть. И то что так можно даже в родных API (JPA, JAXB и т.д.) не оправдание
27 май 21, 14:40    [22328003]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Да и есть хорошее правило что код должен быть - testable by design изначально.

Mockito/PowerMock - играют на особенностях ООП в Java но в то-же время противоречат идеям ООП в принципе.
Поэтому их нельзя считать "честным" тестированием. Тоже самое что если-бы С++ делали reinterpret_cast или что-то
подобное по отношению к инкапсулируемым полям.
27 май 21, 15:17    [22328045]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
gmugar
Eсли класс нельзя на 100% покрыть тестами через его не приватный интерфейс - у тебя плохой дизайн класса. всегда. без исключений.
Логику очень часть неудобно покрывать через public интерфейс. Потому как наружу класс может отдавать только конечные результаты вычислений, а нам удобней протестировать сначала промежуточные результаты. В итоге нам приходится идти на поводу у тестов ухудшая дизайн: разбивать логику на доп классы или же открывать какие-то методы.

Реальный пример: есть робот который умеет переливать жидкость из пробирок в другие пробирки. Одна из команд представленна в виде: ВсосатьЖидкость(сколько, откуда, еще доп параметры). Робот принимает на вход CSV, соответственно классу нужен только один публичный метод: toCsv(). Но в тестах парсить CSV для проверки расчетов очень не удобно из-за чего приходится открывать кой-какие внутренности.

А некоторые вещи тестировать через public API в принципе невозможно. Например, мы не можем протестировать в какой момент HashMap делает rehashing, хотя это обязательная составляющая алгоритма без которой весь класс превращается в тыкву.

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

Сообщение было отредактировано: 27 май 21, 17:16
27 май 21, 17:23    [22328125]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
В данном топике речь идет о тестах на correctness. Здесь мы проверяем бизнес сценарии использования компонентов.

Тесты перформанса (в т.ч) с использованием JMH - это отдельная и сложная тема. Они настолько не похожи
на тесты корректности что я-бы их даже не объединял. В проектах для них создают отдельные группы тестирования
и заводят отдельные фазы CI.

Вообще занятие задачами перформанса - последовательно "калечит код". Это фраза Шипилева. Он даже рисовал
кривую качества кода / перформанса и эта гривая имеля ярко выраженный экстремум. Тоесть была точка где
и код красив и перформанс - более-менее и дальше чтоб хоть немножко (на 2-3%) поднять speed-up нужно
было сломать 50% кода и сделать его нечитабельным и неудобным к использованию. Появляются работы
с byte[], char[], c пакетом unsafe e.t.c.

Яркий пример - BlockingQueue и Disruptor. Если их сравнивать по способу использования то видно что первый - удобен
а второй нет.
27 май 21, 17:49    [22328146]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
gmugar
Member

Откуда:
Сообщений: 23
Stanislav Bashkyrtsev
Логику очень часть неудобно покрывать через public интерфейс. Потому как наружу класс может отдавать только конечные результаты вычислений, а нам удобней протестировать сначала промежуточные результаты. В итоге нам приходится идти на поводу у тестов ухудшая дизайн: разбивать логику на доп классы или же открывать какие-то методы.

Реальный пример: есть робот который умеет переливать жидкость из пробирок в другие пробирки. Одна из команд представленна в виде: ВсосатьЖидкость(сколько, откуда, еще доп параметры). Робот принимает на вход CSV, соответственно классу нужен только один публичный метод: toCsv(). Но в тестах парсить CSV для проверки расчетов очень не удобно из-за чего приходится открывать кой-какие внутренности.

Это вот как раз и есть то, как делать нельзя. Никогда.
Вы тут фактически сказали "мне не удобно тестировать через честное паблик API класса, поэтому я буду срезать углы".
Тем самым закладываются сразу две мины:
1. вы протестировали класс не так как он будет реально использоваться.
2. вы подставили людей, которые при рефакторинге private кишок класса, напорятся на какие-то странные тесты.

Да, бывает протестировать класс сложнее чем его написать.
Да, бывает что тесты в разы больше по размеру, чем собственно лигика которую тестируют.
И наконец, если написать тест реально сдожно, это, опять же, яркий сигнал, что что-то не так с дизаном класса.

Но тестировать приваты - это не номральный путь. В нормальном проекте такое никогда не пройдет code review.
27 май 21, 19:46    [22328184]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
mayton
Тесты перформанса (в т.ч) с использованием JMH - это отдельная и сложная тема.
Я ничего не говорил про JMH и пр. Я не хочу сравнивать две реализации хеш таблиц, я хочу убедиться что свою хеш таблицу с external chaining'ом я реализовал правильно. Т.е. что сам алгоритм написан by the book. И это было бы легко сделать, если бы бакеты были доступны в тестах. Однако это нарушение инкапсуляции.
gmugar
Это вот как раз и есть то, как делать нельзя. Никогда.
Сразу видно что веду дискуссию с опытным человеком :)
gmugar
1. вы протестировали класс не так как он будет реально использоваться.
Я протестирую его и через public API тоже. Но таких тестов я напишу меньше потому как мне останется проверить лишь то что в строку все собирается верно. А саму математику я смогу протестировать нарушив инкапсуляцию.
gmugar
2. вы подставили людей, которые при рефакторинге private кишок класса, напорятся на какие-то странные тесты.
В сложность создания и поддержки проекта входит как написание prod, так и тестового кода. Если мне при рефакторинге прийдется порефакторить так же тесты и я потрачу на это дополнительных 10 мин, я не буду сильно переживать. А если моему коллеге прийдется потратить доп день на написание сложных тестов в которых еще попробуй разберись потом, то не уверен что оценю этот труд. В какой-то момент эти тесты тоже прийдется рефакторить, а т.к. они будут сложными, то этот рефакторинг опять же усложнится.
gmugar
И наконец, если написать тест реально сдожно, это, опять же, яркий сигнал, что что-то не так с дизаном класса.
Это уже какое-то новое правило, я тут идею не совсем понял. Почему сложные тесты - это сигнал плохого дизайна? Я видел много простых тестов в ужасных проектах. И там же видел много сложных тестов. И в хороших проектах видел и те, и другие. В общем не замечал пока никакой корреляции.

Сообщение было отредактировано: 27 май 21, 23:04
27 май 21, 23:10    [22328263]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

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

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

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

Вот такое вот IMHO.
28 май 21, 00:07    [22328270]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
gmugar
Member

Откуда:
Сообщений: 23
Stanislav Bashkyrtsev
Я протестирую его и через public API тоже. Но таких тестов я напишу меньше потому как мне останется проверить лишь то что в строку все собирается верно. А саму математику я смогу протестировать нарушив инкапсуляцию.

При всем уважении, я вашу аргументацию не понимаю и не принимаю.
Если для вас нарушение инкапсуляции это нормально - то мы в разных мирах.

Вы, уже несколько раз написали, что (в вашем примере) так делается потому что через public API тестировать сложно.
Но с каких пор "сложно" стало аргументом в пользу нарушения инкапсуляции?
это аргумент ровно в пользу того, что надо что-то менять чтобы сложно не было.

Stanislav Bashkyrtsev
А если моему коллеге придется потратить доп день на написание сложных тестов в которых еще попробуй разберись потом

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

возвращаюсь к вашему примеру с роботом.
мне отсюда конечно сложно судить, но я бы это просто на два класса разбил:
1. класс который делает расчеты и возвращает их в виде какой-то "простотестируемой" структуры данных
2. класс который по этой структуре данных генерирует CSV

Stanislav Bashkyrtsev
Это уже какое-то новое правило, я тут идею не совсем понял. Почему сложные тесты - это сигнал плохого дизайна? Я видел много простых тестов в ужасных проектах. И там же видел много сложных тестов. И в хороших проектах видел и те, и другие. В общем не замечал пока никакой корреляции.

мой опыт как раз обычно четко показывал эту зависимость.
к самим unit test-ам обычно предъявляют ряд требований. как минимум: Stateless, Easy to write, Readable, Reliable, Fast, "unit, but not integration".
и логика дальше простая:
если тест не соответствуют требованиям - менять тест, чтобы соответсвовал
если привести в соответствие не удается из-за тестируемого кода - менять код, чтобы тест соответсвовал

отсюда появляется понятие Untestable Code и разные проистекающие из этого понятия anti-patters.

"Unit tests also aid the design" (c) Robert C. Martin (Uncle Bob)
28 май 21, 11:32    [22328387]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
gmugar
При всем уважении, я вашу аргументацию не понимаю и не принимаю.
Я не удивлен :)
gmugar
Если для вас нарушение инкапсуляции это нормально - то мы в разных мирах.
Инкапсуляция, как и другие принципы - они не просто из ниоткуда пришли. Если не следовать этим принципам слепо, а понимать зачем и почему, то появляется намного больше вариантов решения проблем. Потому как теперь мы можем взвешивать что хуже: соблюсти этот принцип, но сделать что-то другое сложней. Либо нарушить принцип, но сделать что-то другое проще. Когда встает такой вопрос - мы в любом случае отхватываем проблем, осталось только решить какая из проблем дешевле.
gmugar
но я бы это просто на два класса разбил:
1. класс который делает расчеты и возвращает их в виде какой-то "простотестируемой" структуры данных
2. класс который по этой структуре данных генерирует CSV
Я ждал когда будет предложен этот вариант. Ведь именно он якобы решает все проблемы: и тестировать проще, и инкапсуляцию можем соблюдать. Но:
1. Если этот доп класс будет public, то тут два варианта:
1.а Мы его предаем в конструктор тому кто создает CSV. В таком случае мы усложнили клиентский код. Т.е. ради тестов мы усложнили прод код.
1.б Мы его создаем внутри класса который в итоге генерит CSV. И если мы их тестируем отдельно, то мы предполагаем что CSV класс использует класс вычислениями и тем самым опять же нарушаем инкапсуляцию.
2. Если этот доп класс будет package private, то:
2.а Мы все равно тестируем не Public API. Т.е. по сути это то же самое что тестировать не public метод.
2.б То же что и в 1.б
gmugar
"Unit tests also aid the design" (c) Robert C. Martin (Uncle Bob)
Не верь всему что пишут на заборах.
28 май 21, 14:16    [22328444]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
Stanislav Bashkyrtsev,
+++

gmugar

Вы, уже несколько раз написали, что (в вашем примере) так делается потому что через public API тестировать сложно.
Но с каких пор "сложно" стало аргументом в пользу нарушения инкапсуляции?

А что есть инкапсуляция и что в ней настолько ценного, что ради нее нужно гланды череж ж... лечить?
Если инкапсуляция мешает разработке, тестированию, использованию в продуктиве - да ну нафиг такую инкапсуляцию.
Бизнес задачи писать/решать нужно, а не перед статуей инкапсуляции UML-диаграммы из распечатанных листингов выкладывать.

IMHO
28 май 21, 14:24    [22328450]     Ответить | Цитировать Сообщить модератору
 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]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
Отстал я от жизни. Мои познания в методологиях наверное начала не то, что 2000, а 1990-х годов.

Тогда модно было не TDD, а extrime programming. Вроде как ориентировалось как раз на скорость написание кода. Но одновременное написание теста - одна из основ и в XP.

Т.ч. тесты тестам рознь и со скоростью набивания текста связаны слабо.

AFAIK
3 июн 21, 11:16    [22330800]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
Leonid Kudryavtsev
Отстал я от жизни. Мои познания в методологиях наверное начала не то, что 2000, а 1990-х годов.

Тогда модно было не TDD, а extrime programming. Вроде как ориентировалось как раз на скорость написание кода. Но одновременное написание теста - одна из основ и в XP.

Т.ч. тесты тестам рознь и со скоростью набивания текста связаны слабо.

AFAIK


Ну главное в XP это писать вдвоем, желательно за одним компьютером.

<:o)
3 июн 21, 17:02    [22331012]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Jetbrains там разрабатывал какие-то новые плагины для коллективной разработки.

Кто-то пробовал?
3 июн 21, 17:30    [22331025]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
Stanislav Bashkyrtsev
Ну это лишь значит что у вас слабые аналитика, разработка и, видимо, в целом процессы. У вас в принципе мало шансов на эффективную разработку. Это не значит что у вас ничего не получится, это лишь значит что вы медленно продвигаетесь вперед.

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

Какой то спонтанный выброс эмоций)
зачем мне тдд ,чтобы декомозировать задачи на более маленькие? у вас все настолько плохо с тех.лидом ?
3 июн 21, 17:48    [22331041]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Я вот когда свои структуры данных разрабатывал. Графы там. и прочее. В первую очередь писал тесты.
Это скажем так... сам бох велел.
3 июн 21, 19:21    [22331073]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
mayton
Я вот когда свои структуры данных разрабатывал. Графы там. и прочее. В первую очередь писал тесты.
Это скажем так... сам бох велел.

Звучит так ,Как если бы ты пришел в ресторан и прежде чем выбрать что- то из меню сходил в туалет и покакал в себя)
поняв что TASTE NOT SO GOOD ты выбрал что то иное,из того что ел вчера)
Ну по факту комичная ситуация с TDD - видимо либо аналитики слабые,либо очено мало работы у разрабов- по другому сложно понять - зачем это
3 июн 21, 22:00    [22331115]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
asv79
mayton
Я вот когда свои структуры данных разрабатывал. Графы там. и прочее. В первую очередь писал тесты.
Это скажем так... сам бох велел.

Звучит так ,Как если бы ты пришел в ресторан и прежде чем выбрать что- то из меню сходил в туалет и покакал в себя)
поняв что TASTE NOT SO GOOD ты выбрал что то иное,из того что ел вчера)
Ну по факту комичная ситуация с TDD - видимо либо аналитики слабые,либо очено мало работы у разрабов- по другому сложно понять - зачем это

Если вспомнить что тесты - суть документация (или спека) переписанная кодом - то все становится на места.
Кодишь по спеке - кодишь по TDD.
3 июн 21, 22:09    [22331117]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

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

Звучит так ,Как если бы ты пришел в ресторан и прежде чем выбрать что- то из меню сходил в туалет и покакал в себя)
поняв что TASTE NOT SO GOOD ты выбрал что то иное,из того что ел вчера)
Ну по факту комичная ситуация с TDD - видимо либо аналитики слабые,либо очено мало работы у разрабов- по другому сложно понять - зачем это

Если вспомнить что тесты - суть документация (или спека) переписанная кодом - то все становится на места.
Кодишь по спеке - кодишь по TDD.

возникает один вопрос где взять спеку)тебе такое задатут миллионы разрабов по всему миру и твое ТДД не вытерпит ни какой критики

нет никаких спек в реальном программировании- тока у мастадонотов,да и то не всегда и не везде
да даже у мастадонтов такая там печаль что забей
3 июн 21, 22:14    [22331122]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
asv79
mayton
пропущено...

Если вспомнить что тесты - суть документация (или спека) переписанная кодом - то все становится на места.
Кодишь по спеке - кодишь по TDD.

возникает один вопрос где взять спеку)тебе такое задатут миллионы разрабов по всему миру и твое ТДД не вытерпит ни какой критики

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

Тест - это набор утверждений. Обычно простых. Если на вход бизнес-объекта пришло ... тра-ляля то на выходе .. труляля.
Обычно это хотя-бы 1 раз проговаривают. Хотя-бы сам для себя ты это проговариваешь. Можно говорить - функция.
И мне даже Ф. больше нравится но уж коли мы тут варимся в мире ООП то пускай будет бизнес-объект.
3 июн 21, 22:28    [22331129]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

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

возникает один вопрос где взять спеку)тебе такое задатут миллионы разрабов по всему миру и твое ТДД не вытерпит ни какой критики

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

Тест - это набор утверждений. Обычно простых. Если на вход бизнес-объекта пришло ... тра-ляля то на выходе .. труляля.
Обычно это хотя-бы 1 раз проговаривают. Хотя-бы сам для себя ты это проговариваешь. Можно говорить - функция.
И мне даже Ф. больше нравится но уж коли мы тут варимся в мире ООП то пускай будет бизнес-объект.

смотри если есть некая вменяемая спека -зачем тебе тест?
вот у меня две задачи
одна подходит под TDD - по кафке нам летят месаджи из них я должен собрать два объекта и связать их 1 к многим
тут да можно написать тест - но накой хер он мне?я буду тратить пару дней на это и потом еще 1 на код?)
а тесты юнит я нагенерю за пару часов
ну и вторая задача это прикрутить АБАК - никто не знает ничего что надо и что должно быть - нука прикрути сюда свой ТДД)

шляпа это все ,как правильно сказал выше памфилов- просто какой то дурак сказал и все начали повторять
3 июн 21, 22:38    [22331132]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
asv79
зачем мне тдд ,чтобы декомозировать задачи на более маленькие?
Кто-то что-то говорил про декомпозицию задач?
Книгу по TDD ты видимо не читал. Когда тут тебе рассказывают что такое TDD ты тоже не особо вчитываешься. Т.е. ты влезаешь в дискуссию в которой заведомо не разбираешься и учиться не отказываешься. Осталось только понять зачем :)
3 июн 21, 22:42    [22331135]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

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

смотри если есть некая вменяемая спека -зачем тебе тест?
вот у меня две задачи
одна подходит под TDD - по кафке нам летят месаджи из них я должен собрать два объекта и связать их 1 к многим
тут да можно написать тест - но накой хер он мне?я буду тратить пару дней на это и потом еще 1 на код?)
а тесты юнит я нагенерю за пару часов
ну и вторая задача это прикрутить АБАК - никто не знает ничего что надо и что должно быть - нука прикрути сюда свой ТДД)

шляпа это все ,как правильно сказал выше памфилов- просто какой то дурак сказал и все начали повторять

Панфилов сказал что не нужно бездумно повторять. Вот ты поменяешь проект (кто знает) и придешь вникать
в новые процессы. А там окажется и команда и весь облуживающий персонал сидят на TDD просто потому что
предметная область такова. И условия подходящие. Что возмутишся? Или скажешь - я не буду делать? Хер
там. Сядешь, утрёшь слёзы и погнал кодить по TDD. Так што от тюрмы и от сумы....
3 июн 21, 22:47    [22331136]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
Stanislav Bashkyrtsev
asv79
зачем мне тдд ,чтобы декомозировать задачи на более маленькие?
Кто-то что-то говорил про декомпозицию задач?
Книгу по TDD ты видимо не читал. Когда тут тебе рассказывают что такое TDD ты тоже не особо вчитываешься. Т.е. ты влезаешь в дискуссию в которой заведомо не разбираешься и учиться не отказываешься. Осталось только понять зачем :)

я прекрасно знаю что такое ваше печальное ТДД и имел опыт работы с таким подходом)
вот ты стасят вроде и норм местами,но вешаешь ярлыки не разобравшись в проблеме)
4 июн 21, 00:37    [22331151]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

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

смотри если есть некая вменяемая спека -зачем тебе тест?
вот у меня две задачи
одна подходит под TDD - по кафке нам летят месаджи из них я должен собрать два объекта и связать их 1 к многим
тут да можно написать тест - но накой хер он мне?я буду тратить пару дней на это и потом еще 1 на код?)
а тесты юнит я нагенерю за пару часов
ну и вторая задача это прикрутить АБАК - никто не знает ничего что надо и что должно быть - нука прикрути сюда свой ТДД)

шляпа это все ,как правильно сказал выше памфилов- просто какой то дурак сказал и все начали повторять

Панфилов сказал что не нужно бездумно повторять. Вот ты поменяешь проект (кто знает) и придешь вникать
в новые процессы. А там окажется и команда и весь облуживающий персонал сидят на TDD просто потому что
предметная область такова. И условия подходящие. Что возмутишся? Или скажешь - я не буду делать? Хер
там. Сядешь, утрёшь слёзы и погнал кодить по TDD. Так што от тюрмы и от сумы....

Никода я не буду кодить по ТДД,ибо это уже не кодинг,а какая то ферма по выращиваниванию овощей
Мне нужен полет фантазии и прочие ништяки,а свое ТДД засуньте себе ЖПО и будьте здоровы)
4 июн 21, 00:40    [22331152]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

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

Панфилов сказал что не нужно бездумно повторять.

панфилов сказал то что сказал и там явно не то что ты сейчас написал
По факту ТДД нужно для просто каких то конченых даунов ,которые не способны реализовать задачу иначе,чем через уже готовый тест
4 июн 21, 00:53    [22331154]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
asv79, мне нравится твой неприкрытый максимализм.
4 июн 21, 10:14    [22331215]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
gmugar
Member

Откуда:
Сообщений: 23
Stanislav Bashkyrtsev
gmugar
новый публичный метод(e.g. getResults()), который возвращает результаты в виде какой-то удобной (и unmodifiable) структуры,

Ну вот ты открыл метод который до этого был private или package private (если мы его таки открывали для тестирования). Что здесь принципиально поменялось? Т.е. если этот метод лежал в старом классе, то тебе не нравилось его открывать только для тестирования. А если его перенести в другой класс и сделать public, то так открывать код чисто для тестирования - правильно. Почему?
gmugar
он не раскрывает никаких кишок класса; по сути, это те же данные, которые клиенты уже получают посредством toCsv(), просто в другом формате

Плохо тут то что у нас +1 публичная сущность. До этого я видел с какими классами в пакете мне нужно было взаимодействовать, а теперь оказывается есть public классы которые на самом деле мне не нужны. Но эта проблема решается - твой новый класс можно сам по себе сделать package private, т.е. он не будет виден из-вне пакета. Но опять же - в чем разница метод открывать или класс?

мы с вами по кругу ходим.
напомню, что изначально вопрос был в том нужно ли тестировать private методы.
речь шла о private, а не о package-private, что не одно и то же.
моя мысль в том, что если, вдруг, без тестирования через private не получается (с соблюдением концепции хорошего unit-теста, одна из важных особенностей которого - простота написание этого самого unit-теста), то надо что-то менять, а не лезть в private.
4 июн 21, 11:52    [22331261]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
gmugar
Stanislav Bashkyrtsev
пропущено...

Ну вот ты открыл метод который до этого был private или package private (если мы его таки открывали для тестирования). Что здесь принципиально поменялось? Т.е. если этот метод лежал в старом классе, то тебе не нравилось его открывать только для тестирования. А если его перенести в другой класс и сделать public, то так открывать код чисто для тестирования - правильно. Почему?
пропущено...

мы с вами по кругу ходим.
напомню, что изначально вопрос был в том нужно ли тестировать private методы.
речь шла о private, а не о package-private, что не одно и то же.
моя мысль в том, что если, вдруг, без тестирования через private не получается (с соблюдением концепции хорошего unit-теста, одна из важных особенностей которого - простота написание этого самого unit-теста), то надо что-то менять, а не лезть в private.
Ну дак то что ты предлагаешь сделать - это и есть лезть в private. Твое предложение заключается в том чтоб просто открыть приватный код, выделив его в отдельный класс. Я лишь хочу заметить что это ничем по своей сути не отличается от того чтоб сделать приватный метод package private оставив его в изначальном классе. В обоих случаях мы открываем private код.

А правильный "не лезть в private" заключается в том чтоб оставить prod код в покое и тестировать все через настоящий public API (а не сконструированный только потому что тестам надо было). Со всеми вытекающими плюсами и минусами.

Сообщение было отредактировано: 4 июн 21, 11:57
4 июн 21, 11:58    [22331265]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Мы скоро дойдем до Java9 модулей. Мне кажется спор - схоластика вокруг ООП. Что считать приватным и полу-приватным.

Ведь это же не важно. А важно чтобы бизнес-кейс прошел на 100% в зеленый сегмент тестирования.
4 июн 21, 12:23    [22331285]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
gmugar
Member

Откуда:
Сообщений: 23
Stanislav Bashkyrtsev
А правильный "не лезть в private" заключается в том чтоб оставить prod код в покое и тестировать все через настоящий public API (а не сконструированный только потому что тестам надо было). Со всеми вытекающими плюсами и минусами.

с этим, собственно, никто и не спорит.
вообще тестировать нужно только, этот самый, "настоящий public API".

но вот c "логику очень часть неудобно покрывать через public интерфейс."(это ваши слова), я не согласен в корне.
мой опыт, однозначно, не совпадает с этой точкой зрения.
4 июн 21, 12:26    [22331288]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 8254
Народ (прогеры) уверяет в веб, что при тестах скорость снижается только первые два года их написания.
Зато потоооооом))
4 июн 21, 12:36    [22331299]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
Stanislav Bashkyrtsev
Ну дак то что ты предлагаешь сделать - это и есть лезть в private. Твое предложение заключается в том чтоб просто открыть приватный код, выделив его в отдельный класс. Я лишь хочу заметить что это ничем по своей сути не отличается от того чтоб сделать приватный метод package private оставив его в изначальном классе. В обоих случаях мы открываем private код.

А правильный "не лезть в private" заключается в том чтоб оставить prod код в покое и тестировать все через настоящий public API (а не сконструированный только потому что тестам надо было). Со всеми вытекающими плюсами и минусами.


Не совсем. Если нужно протестировать private метод, это значит, что этот метод не может быть private.
И скорее всего там где-то нарушен принцип "single responsibility principle".
Так что вынести логику в отдельный класс это скорее всего правильное решение.
4 июн 21, 13:24    [22331329]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
mad_nazgul
Stanislav Bashkyrtsev
Ну дак то что ты предлагаешь сделать - это и есть лезть в private. Твое предложение заключается в том чтоб просто открыть приватный код, выделив его в отдельный класс. Я лишь хочу заметить что это ничем по своей сути не отличается от того чтоб сделать приватный метод package private оставив его в изначальном классе. В обоих случаях мы открываем private код.

А правильный "не лезть в private" заключается в том чтоб оставить prod код в покое и тестировать все через настоящий public API (а не сконструированный только потому что тестам надо было). Со всеми вытекающими плюсами и минусами.


Не совсем. Если нужно протестировать private метод, это значит, что этот метод не может быть private.
И скорее всего там где-то нарушен принцип "single responsibility principle".
Так что вынести логику в отдельный класс это скорее всего правильное решение.
Ну вот же я приводил пример:
Stanislav Bashkyrtsev
Реальный пример: есть робот который умеет переливать жидкость из пробирок в другие пробирки. Одна из команд представленна в виде: ВсосатьЖидкость(сколько, откуда, еще доп параметры). Робот принимает на вход CSV, соответственно классу нужен только один публичный метод: toCsv(). Но в тестах парсить CSV для проверки расчетов очень не удобно из-за чего приходится открывать кой-какие внутренности.
В этом примере SRP не поможет. Просто мы будем тестировать либо CSV, либо прийдется открывать поля класса через те же package private или public getter'ы. Здесь явно нарушается инкапсуляция только ради тестов. И это частая проблема. Просто люди так много слышат что тесты якобы улучшают дизайн, что пытаются отгонять от себя эти темные мысли :D
gmugar
вообще тестировать нужно только, этот самый, "настоящий public API".
Наша песня хороша - начинай сначала :)
4 июн 21, 14:15    [22331373]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
Stanislav Bashkyrtsev
Просто люди так много слышат что тесты якобы улучшают дизайн

Вообще практическая польза тестов стремится к нулю
по факту они ипользуются лишь при сборке и потом приложение попадает на тестовые стенды ,где даже если бы тестов не было - все это вылезет 100500 тысяч миллионов раз и без всяких юнит тестов
Тоесть просто выкидываем деньги на ветер- тратя время разрабов на создание и что не мало важно поддержку этой юзлесс истории
Стандартная ситуация - написаны тесты,поступила задача поменять какой то класс ,который учавствовал в тесте- фигах тесты падают- хотя фактически все норм,просто тест уже неактуален и вот ты идешь ее актуализировать
Получается порочный круг ,вместо какой то видимой помощи,тесты наоборот замедляют работу разработчиков

Вот что по сути нужно,это коменнты на коде - ты тут нагадил - а потом после тебя люди приходят и гадают ,а что это такое и что он хотел- доходит до такого ,что никто не в состоянии понять для чего вот это поле в классе и какой в нем смысл)

Я не против тестов ,как таковых - но какой то продуктивной пользы в них не вижу от слова совсем и есть конторы где с тестами носятся как с писаной торбой,а есть где этих тестов нет и все прекрасно работает и развивается в своем ключе без них
4 июн 21, 14:53    [22331399]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
asv79, тыж в банке верно? Значит в разработке есть своя цена ошибки.

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

То что ты говоришь про тестовые стенды - это другая часть работы. Это наверное отвественность QA.
Но QA не тестирует нефункциональное минорное и техническое. Всякие там NPE и прочее. Они конешно
могут это найти случайно. Но репутация сектора разработки тоже страдает. Выж не должны выкатывать
забагованный по самую крышу рализ-кандидат. Надо как-то проявить аккуратность. Репутационный вопрос
вобщемто.
4 июн 21, 15:02    [22331409]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

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

Вот что по сути нужно,это коменнты на коде - ты тут нагадил - а потом после тебя люди приходят и гадают ,а что это такое и что он хотел- доходит до такого ,что никто не в состоянии понять для чего вот это поле в классе и какой в нем смысл)

По поводу каментов в коде. Мой опыт показывает что их не актуализируют. Тоесть грубо говоря ты написал
тонну текста. Потом зашел другой разраб. Код поменял а камент проигнорил. Далее - ситуация усугубляется.
Есть код и есть текст которые друг другу противоречат. И если контроль над кодом идет через тестирование
то контроля над каментами нет вообще никакого. Дай бох его прочитают во время код-ревью и дадут по шапке.

Но я готов спорить на виски (и выигрывать) что нечитают и не актуализируют.

Или нужно иметь на проекте отдельного человека (теч-райтера) который будет буквально отвечать за документацию
в Doxia, JavaDoc, Confluence e.t.c.

Сообщение было отредактировано: 4 июн 21, 15:04
4 июн 21, 15:12    [22331419]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
mayton
asv79, тыж в банке верно? Значит в разработке есть своя цена ошибки.

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

То что ты говоришь про тестовые стенды - это другая часть работы. Это наверное отвественность QA.
Но QA не тестирует нефункциональное минорное и техническое. Всякие там NPE и прочее. Они конешно
могут это найти случайно. Но репутация сектора разработки тоже страдает. Выж не должны выкатывать
забагованный по самую крышу рализ-кандидат. Надо как-то проявить аккуратность. Репутационный вопрос
вобщемто.

в банке - и вот честно скажу за 2 года работы я ни разу не видел такого момента,чтобы эти тесты что то там отловили,кроме того,что при любых изменениях приходится еще и тесты актуализировать - по факту двойная работа.
Я могу тебе сказать как произсходит приемка релиза,сначала все это тестируют QА,потом это выкатывается все на препрод ,где уже проходит ПСИ ,далее прод с двух недельным гарантийным обязательством- далее этот релиз уходит из нашей зоны ответственности
тоесть понятно что баги могут вылезти и они вылазят вне зависимости от тестов

по факту при сборке в ста случаях из ста за мою практику когда падает тест- ты идешь и правишь тест)вот и вся цена этим тестам
4 июн 21, 17:13    [22331509]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
Странная практика, странная статистика

Юнит тесты они еще и как регрессивные тесты работают. Если при серьезном модификации кода, тесты ни разу ни одной ошибки не нашли то:
1. или программисты святые и ошибок не допускают
2. или серьезной модификации кода не делали
3. или тесты - .....

IMHO
4 июн 21, 17:24    [22331516]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

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

Вот что по сути нужно,это коменнты на коде - ты тут нагадил - а потом после тебя люди приходят и гадают ,а что это такое и что он хотел- доходит до такого ,что никто не в состоянии понять для чего вот это поле в классе и какой в нем смысл)

По поводу каментов в коде. Мой опыт показывает что их не актуализируют. Тоесть грубо говоря ты написал
тонну текста. Потом зашел другой разраб. Код поменял а камент проигнорил. Далее - ситуация усугубляется.
Есть код и есть текст которые друг другу противоречат. И если контроль над кодом идет через тестирование
то контроля над каментами нет вообще никакого. Дай бох его прочитают во время код-ревью и дадут по шапке.

Но я готов спорить на виски (и выигрывать) что нечитают и не актуализируют.

Или нужно иметь на проекте отдельного человека (теч-райтера) который будет буквально отвечать за документацию
в Doxia, JavaDoc, Confluence e.t.c.

да к сожалению это так и есть.
Не тесты конечно есть и полезные- например те,которые чекают время запроса,выполенния метода,записи там в бд и тд
где по SLA мы видим вкатываемся мы в нормы
4 июн 21, 17:26    [22331522]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

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

в банке - и вот честно скажу за 2 года работы я ни разу не видел такого момента,чтобы эти тесты что то там отловили,кроме того,что при любых изменениях приходится еще и тесты актуализировать - по факту двойная работа.
Я могу тебе сказать как произсходит приемка релиза,сначала все это тестируют QА,потом это выкатывается все на препрод ,где уже проходит ПСИ ,далее прод с двух недельным гарантийным обязательством- далее этот релиз уходит из нашей зоны ответственности
тоесть понятно что баги могут вылезти и они вылазят вне зависимости от тестов

по факту при сборке в ста случаях из ста за мою практику когда падает тест- ты идешь и правишь тест)вот и вся цена этим тестам

Посмотри Code-coverage. Sonar показывает или Jacoco плагин.

Возможно у тебя нужный и полезный код просто не покрыт.
4 июн 21, 17:34    [22331528]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

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

Не тесты конечно есть и полезные- например те,которые чекают время запроса,выполенния метода,записи там в бд и тд
где по SLA мы видим вкатываемся мы в нормы

SLA/Performance - это немножко другое. Это не про correctness а это фактически проверка того что изменения
не просадили перформанс. И эти тесты не закрепляют бизнес-логику. Обычно такая задача перед ними
не стоит. Они утверждают например что скорость канала месседжей например не меньше чем 100 штук в секунду.
Понятное дело что такие тесты не будут ловить логические баги. А они скорее закрепляют собой инфра-структурные
метрики. Сеть там... сервисы.

Сообщение было отредактировано: 4 июн 21, 17:38
4 июн 21, 17:47    [22331536]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

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

в банке - и вот честно скажу за 2 года работы я ни разу не видел такого момента,чтобы эти тесты что то там отловили,кроме того,что при любых изменениях приходится еще и тесты актуализировать - по факту двойная работа.
Я могу тебе сказать как произсходит приемка релиза,сначала все это тестируют QА,потом это выкатывается все на препрод ,где уже проходит ПСИ ,далее прод с двух недельным гарантийным обязательством- далее этот релиз уходит из нашей зоны ответственности
тоесть понятно что баги могут вылезти и они вылазят вне зависимости от тестов

по факту при сборке в ста случаях из ста за мою практику когда падает тест- ты идешь и правишь тест)вот и вся цена этим тестам

Посмотри Code-coverage. Sonar показывает или Jacoco плагин.

Возможно у тебя нужный и полезный код просто не покрыт.

у нас покрыто все - сам понимаешь зона отвественности- хотя как я уже говорил - толку просто ноль
а вот slшки - как раз очень часто помогают,так как сам понимаешь на хайлоад системах очень важны такие моменты
4 июн 21, 18:53    [22331575]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
asv79
mayton
пропущено...

Посмотри Code-coverage. Sonar показывает или Jacoco плагин.

Возможно у тебя нужный и полезный код просто не покрыт.

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

Ты выше пишешь про "двойную работу". Тесты должны писаться так чтобы их поддержка не занимала столько-же
времени сколько и написание основного кода. Если у вас тесты настолько сложны и трудозатратны - то проанализируйте
ГДЕ сложно и просто выкиньте это из покрытия. Перепишите проще. Выкиньте @SpringBoorTest. Напишите обычные
без фреймворка. Если бизнес функция не позволяет - выделите функцию в чистый (pure) java class. Обычно
мне это всегда удавалось. И жить будет проще.
4 июн 21, 19:00    [22331581]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

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

Ты выше пишешь про "двойную работу". Тесты должны писаться так чтобы их поддержка не занимала столько-же
времени сколько и написание основного кода. Если у вас тесты настолько сложны и трудозатратны - то проанализируйте
ГДЕ сложно и просто выкиньте это из покрытия. Перепишите проще. Выкиньте @SpringBoorTest. Напишите обычные
без фреймворка. Если бизнес функция не позволяет - выделите функцию в чистый (pure) java class. Обычно
мне это всегда удавалось. И жить будет проще.[/quot]
любая поддержка это уже поддержка,будь то самые простые юнит тесты или интеграционные - их нужно постоянно актуализировать
когда много кода,тестов тоже много,зачастую при даже не самом большом рефакторинге приходится делать сопоставимый объем работы и в тестах-это супер накладно ,нулевое бизнес велью ,около нулевое девелопер велью
ну может ток тестировшики тебе спасибо скажут ,что один раз в тысячу лет ты что то там тестами этими не пропустил)
4 июн 21, 23:50    [22331678]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
Leonid Kudryavtsev
Странная практика, странная статистика

Юнит тесты они еще и как регрессивные тесты работают. Если при серьезном модификации кода, тесты ни разу ни одной ошибки не нашли то:
1. или программисты святые и ошибок не допускают
2. или серьезной модификации кода не делали
3. или тесты - .....

IMHO

при серьезной модификации кода тесты ломаются и это очевидно что их приходится актуализировать- что может там поймать поломанный тест?
программисты не святые,но есть жеское код ревью - я знаю ,что во многих конторах на эту часть разработки почему то кладут болт,а потом у них тесты краснеют - что не удивительно)
4 июн 21, 23:52    [22331679]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
asv79, слышал про PBT?
5 июн 21, 12:03    [22331720]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

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

Ты выше пишешь про "двойную работу". Тесты должны писаться так чтобы их поддержка не занимала столько-же
времени сколько и написание основного кода. Если у вас тесты настолько сложны и трудозатратны - то проанализируйте
ГДЕ сложно и просто выкиньте это из покрытия. Перепишите проще. Выкиньте @SpringBoorTest. Напишите обычные
без фреймворка. Если бизнес функция не позволяет - выделите функцию в чистый (pure) java class. Обычно
мне это всегда удавалось. И жить будет проще.


Ну ты сказал!
Может ещё "Чистый код" посоветуешь почитать?!
Какое еще single responsibility!
Тут таску надо закрывать, а не тесты писать!

<:o)
8 июн 21, 09:12    [22332662]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
При чем тут чистый код? Чувак неделю пишет user story. Потом еще неделю - тесты по ней.
8 июн 21, 11:01    [22332718]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
mayton
При чем тут чистый код? Чувак неделю пишет user story. Потом еще неделю - тесты по ней.


При том, что тестируемость, ходит где-то рядом с чистым кодом и принципом single responsibility :-)
Когда принцип single responsibility нарушается, то сразу возникает вопрос как тестировать private-методы :-)
8 июн 21, 12:07    [22332770]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
mad_nazgul
Когда принцип single responsibility нарушается, то сразу возникает вопрос как тестировать private-методы :-)
Ты все повторяешь эти мантры, но на свой простенький пример я так и не получил никакого внятного предложения. Чтоб без доступа к private методам, да еще и удобно.
8 июн 21, 13:18    [22332826]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
lleming
Member

Откуда:
Сообщений: 1787
mad_nazgul
mayton
При чем тут чистый код? Чувак неделю пишет user story. Потом еще неделю - тесты по ней.


При том, что тестируемость, ходит где-то рядом с чистым кодом и принципом single responsibility :-)
Когда принцип single responsibility нарушается, то сразу возникает вопрос как тестировать private-методы :-)


Я к похожему умозаключению пришел, один из заказчиков потребовал 100 процентное покрытие. Если закрыть тяжело все кейсы приватного метода закрыть через публичный то значит скорее всего приватный метод не должен быть приватным, и нужно выносить в отдельный класс ибо слишком много он делает.
8 июн 21, 15:11    [22332938]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Leonid Kudryavtsev
Member

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

...
при серьезной модификации кода тесты ломаются и это очевидно что их приходится актуализировать- что может там поймать поломанный тест?

1. модификация бывает не только с изменением функциональности. Например:
1.1. перформанс
1.2. рефакторинг
1.3. переход на новые библиотеки/принципы взаимодействия (например я мигрировал большой проект с tcp/ip socket на nio)
и так далее и так далее
2. даже если и новые добавочные требования к функциональности, то обычно они НЕполностью заменяют старые, а лишь в какой-то части. И самое сложное, убедится, что "мелкое" исправление не поломало старый функционал
и так далее и так далее

И так вроде очевидно, для чего нужно regression test'ы. Нормые unit test'ы, обычно regression вполне заменяют и проблемы реально находят и помогают их решать.

AFAIK.
8 июн 21, 16:30    [22332987]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Некоторые - вкладываются в страховку. Некоторые - нет. Скорее от проекта зависит. Я видел некоторые UI
проекты в которых вообще ни одного авто-теста нет. Там - полностью полагаются на мануальное тестирование.
Поэтому тестировать или нет - это договорённость в команде. Самому продакт-овнеру вобщем-то все равно
пишем мы тесты или нет.

А так - по топику вообще-то ответ всем очевиден.
8 июн 21, 18:21    [22333036]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
am_sasa
Member

Откуда:
Сообщений: 718
mayton
некоторые UI
проекты в которых вообще ни одного авто-теста нет. Там - полностью полагаются на мануальное тестирование
Ровно так и делали свои web проекты, т.к. там был REST и почти все изменения - это исправление sql и js, как бы... тестировать нечего
9 июн 21, 13:19    [22333263]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
am_sasa
mayton
некоторые UI
проекты в которых вообще ни одного авто-теста нет. Там - полностью полагаются на мануальное тестирование
Ровно так и делали свои web проекты, т.к. там был REST и почти все изменения - это исправление sql и js, как бы... тестировать нечего


Вот js - нужно постоянно тестировать. :-)

А SQL просто сложно тестировать, т.к. инструменты для тестирования около нуля.
9 июн 21, 15:56    [22333373]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Поскольку SQL является декларативным языком то он изначально декларирует свой результат.
Хотя я согласен что текст SQL может быть длинными и содержащим вложенные SQL и функции.
Но есть качественная разница между SQL и императивным языком. Это примерно как разница
между maven и gradle.

Кроме того инструмент тестирования должен быть проще объекта тестирования. Иначе возникает
другой парадокс о правильности самого инструмента и его statement. Или надо писать тест на тест.
9 июн 21, 16:17    [22333394]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
mayton
Поскольку SQL является декларативным языком то он изначально декларирует свой результат.
Хотя я согласен что текст SQL может быть длинными и содержащим вложенные SQL и функции.
Но есть качественная разница между SQL и императивным языком. Это примерно как разница
между maven и gradle.
Какая разница декларативен он или нет? Я в SQL много багов встречаю как минимум потому что мы не все про данные знаем/помним, какие-то моменты забываются и опа - миграция свалилась. Или того хуже - прошла, но неверно. Плюс бывает не по той ветке join'ов пошли и собрали не те данные.
mayton
Кроме того инструмент тестирования должен быть проще объекта тестирования. Иначе возникает
другой парадокс о правильности самого инструмента и его statement. Или надо писать тест на тест.
Не знаю откуда такие требования взялись. Как инструмент для тестирования, так и сами тесты могут быть значительно сложней основного кода. И сил нужно будет потратить на тестирование намного больше чем на написание прод кода.

Все зависит от того сколько гарантий мы хотим получить, насколько важно чтоб код работал верно. Если мы пишем какое-то второстепенное ПО для банка - народ переживет даже если оно совсем работать не будет. А если это софт для управления самолетами, ракетами, АЭС - то тут же совсем другой разговор. Тут и PBT, и MBT, и чего только не прийдется использовать. И конечно же сами инструменты для тестирования должны быть протестированы.

Сообщение было отредактировано: 9 июн 21, 16:24
9 июн 21, 16:31    [22333401]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Stanislav Bashkyrtsev
Какая разница декларативен он или нет? Я в SQL много багов встречаю как минимум потому что мы не все про данные знаем/помним, какие-то моменты забываются и опа - миграция свалилась. Или того хуже - прошла, но неверно. Плюс бывает не по той ветке join'ов пошли и собрали не те данные.

А можно пример такого бага? И мне также интересно как вы подготавливаете данные для подобного тестирования?
9 июн 21, 16:37    [22333406]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

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

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

Хотел бы я на это посмотреть.

Если вы доказываете теорему Пифагора - вы можете привлекать рассуждения более простого порядка чем
сама теорема. Можете брать аксиомы.

Но вы не можете доказать теорему Пифагора через Теорему Косинусов. Это абсурд. Никто не примет такое
доказательство.
9 июн 21, 16:39    [22333408]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
mayton
Stanislav Bashkyrtsev
Какая разница декларативен он или нет? Я в SQL много багов встречаю как минимум потому что мы не все про данные знаем/помним, какие-то моменты забываются и опа - миграция свалилась. Или того хуже - прошла, но неверно. Плюс бывает не по той ветке join'ов пошли и собрали не те данные.

А можно пример такого бага?
Ну из своего проекта я конечно приводить примеров не буду, ну вот что-то подобное, синтезированное:
1. Решили для упрощения бизнес логики явно писать в БД имеет ли пользователь доступ к объекту или нет (вместо того чтоб вычислять на лету). Написали миграцию, которая проставляет флаг=true если пользователю >18. Но оказалось, что есть исключение - страна, в которой доступ можно разрешать только с 16. И админам (у которых возраст может быть не указан) тоже разрешать.
2. Добавляем новую колонку, знаем что она not null. Сразу же проставили constraint (а след строкой заполняем данными), хотя в таблице есть строки.
3. ... и т.д.

mayton
И мне также интересно как вы подготавливаете данные для подобного тестирования?
Мы редко пишем на это тесты. Но если пишем - ну заполняем данными, затем запускаем миграцию, затем проверяем результат. Это больше для background миграций, которые идут длительное время. Для таких приложение должно поддерживать и старые, и новые данные.

А так.. как правило у нас есть дамп с прода - на нем куа тестируют вручную. Проходятся по своей тестовой документации, вспоминают что могли упустить, анализируют результат.
mayton
Но вы не можете доказать теорему Пифагора через Теорему Косинусов. Это абсурд. Никто не примет такое
доказательство.
Во-первых, в математике бывает что доказывают/высчитывают что-то более простое какими-то более сложными (я счас не говорю про цикличность) абстракциями. Типа посчитать площадь четырехугольника с помощью cross product'a двух векторов. А во-вторых, мы про доказательства (где цикличность нежелательна) ничего не говорили - мы говорим про протестировать. А тут уж крути-верти как хочешь, твоя задача просто написать два куска кода результат которых будет совпадать.

Ну и возьмем что-то наглядное.. Вот к примеру вынесли зачем-то операцию умножения в функцию и хотим протестировать. Реализовать такое легко, а написать PBT тесты, да еще и не заглядывая в википедию - эт уже не каждый сможет.

Другой пример (более реалистичный) - test oracle. Хотим какую-то структуру данных реализовать. Более простую чем что-то существующее в Java SDK, с меньшим функционалом, но быстрей. Как мы ее будем тестировать? Можем написать MBT с использованием стандартной реализации в качестве модели. И получается тестируем более простой код более сложным.

Третий пример (еще реалистичней) - написали какую-то concurrent структуру данных. И вот тут попробуй еще написать тесты которые бы выявили многопоточные проблемы..

Сообщение было отредактировано: 9 июн 21, 17:06
9 июн 21, 17:12    [22333432]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Stanislav Bashkyrtsev
mayton
пропущено...

А можно пример такого бага?
Ну из своего проекта я конечно приводить примеров не буду, ну вот что-то подобное, синтезированное:
1. Решили для упрощения бизнес логики явно писать в БД имеет ли пользователь доступ к объекту или нет (вместо того чтоб вычислять на лету). Написали миграцию, которая проставляет флаг=true если пользователю >18. Но оказалось, что есть исключение - страна, в которой доступ можно разрешать только с 16. И админам (у которых возраст может быть не указан) тоже разрешать.
2. Добавляем новую колонку, знаем что она not null. Сразу же проставили constraint (а след строкой заполняем данными), хотя в таблице есть строки.
3. ... и т.д.

Задачи миграции. Апгрейда версий. Или просто одноразовые скрипты - это штучный товар. Они делаются 1 раз в жизни
и исполняются один раз. И тестирование для них нужно особое. Я-б даже сказал это не периодическое тестирование
а эксклюзивное. Можно договариваться заранее с админами БД Oracle например о подготовке flashback сразу после
неудачной миграции. Вобщем все это напоминает полёт на луну. Неформализовываемое. И бесконечно сложное
по комплексности.
9 июн 21, 18:09    [22333472]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Stanislav Bashkyrtsev
Мы редко пишем на это тесты. Но если пишем - ну заполняем данными, затем запускаем миграцию, затем проверяем результат. Это больше для background миграций, которые идут длительное время. Для таких приложение должно поддерживать и старые, и новые данные.

А так.. как правило у нас есть дамп с прода - на нем куа тестируют вручную. Проходятся по своей тестовой документации, вспоминают что могли упустить, анализируют результат.

Вот это самое интересное. Обычный разработчик софта оперирует кодом. Данные для него либо - синтетические.
Которые он создает сам. В этом случае он должен фактически выполнить работу по наполнению БД насколько
чтобы покрыть максимум краевых кейсов своего запроса. Насколько сложна эта работа? Я думаю - соизмерима
с разработкой основной user-story.

Либо данные - продуктовые. Дамп с прода - тоже интересная задача. Во многих организациях ИБ
его просто не позволит сделать. Прод - слишком ценен. Для этого придумывают невообразимые
трансформации данных (отбеливание) с целью убить любую sensitive инфу и обезличить данные кастомера.
Это эпика. Мдя. Тут можно отдельный программный продукт создавать. Отбеливатель. Со своими настройками.
9 июн 21, 18:16    [22333478]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
mayton
Поскольку SQL является декларативным языком то он изначально декларирует свой результат.
Хотя я согласен что текст SQL может быть длинными и содержащим вложенные SQL и функции.
Но есть качественная разница между SQL и императивным языком. Это примерно как разница
между maven и gradle.


"Бойся своих желаний они могут исполнится" :-)
Так же и с SQL.
Ты получаешь то что запрашиваешь.
Но может оказаться, что запрос не правильный.
И возвращает не то что нужно.
Хотя страшнее когда он возвращает не только то что нужно и/или не всё что только нужно. :-)

mayton

Кроме того инструмент тестирования должен быть проще объекта тестирования. Иначе возникает
другой парадокс о правильности самого инструмента и его statement. Или надо писать тест на тест.


Вот поэтому и "двигают в народ" unit-test.
Т.к. проще написать такой тест, проще протестировать.
Да и инструментарий очень простой.

Другое дело интеграционные тесты.
Там как раз вылазит NP-полная задача (с комбинаторным взрывом) тестирования всех веток БЛ.
Поэтому интеграционные тесты не могут быть простыми.
10 июн 21, 09:30    [22333597]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

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

Третий пример (еще реалистичней) - написали какую-то concurrent структуру данных. И вот тут попробуй еще написать тесты которые бы выявили многопоточные проблемы..

Это - еще сложнее. Я не знаю тестов которые доказывают что мультипоточный код не содержит к примеру дедлоков.
Была теория (кажется на базе сетей Петри) что подобные вещи доказывают делая преобразования матриц переходов
(transition matrix) для сети которая моделирует проблему. Но эта теория осталась в универах и я никогда не видел
чтобы хоть один разработчик ею пользовался. Зачастую только PROD-эксплуатация показывает что в мультипоточном
коде есть проблема.
10 июн 21, 11:17    [22333647]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
mayton
Stanislav Bashkyrtsev

Третий пример (еще реалистичней) - написали какую-то concurrent структуру данных. И вот тут попробуй еще написать тесты которые бы выявили многопоточные проблемы..

Это - еще сложнее. Я не знаю тестов которые доказывают что мультипоточный код не содержит к примеру дедлоков.
Была теория (кажется на базе сетей Петри) что подобные вещи доказывают делая преобразования матриц переходов
(transition matrix) для сети которая моделирует проблему. Но эта теория осталась в универах и я никогда не видел
чтобы хоть один разработчик ею пользовался. Зачастую только PROD-эксплуатация показывает что в мультипоточном
коде есть проблема.
Ну сети петри не обязательны, но в целом да - эта проблема решается с помощью Model Based Testing. Сам я многопоточность никогда не тестировал (да и толком не писал, что уж там), но периодически слышу что такой подход применяют на практике.
10 июн 21, 11:44    [22333663]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
gmugar
Member

Откуда:
Сообщений: 23
а знаете ли вы, что концепции unit-test более чем 40 лет? (первые публикации по теме были в конце 70-ых прошлого века)
и как-то никто особо и не пользовался...

а почему так? IMHO, потому что @asv79 во многом прав: unit-test - не серебряная пуля.
1. это очень дорого: хорошие unit-test-ы и хорошее покрытие = +50% к бюджету проекта как минимум
2. и даже покрытие в 100% не избавляет совершенно от других видов тестирования; не говоря о том, что есть целые классы задач для которых unit-test-ы бесполезны или очень слабо полезны (как и обсуждалось выше)

далёкий от IT бизнес, по сей день, не понимает зачем это надо (сталкиваюсь постоянно)

я подозреваю, что первый реальный пропагандист: Kent Beck.
он написал о них в своей мега популярной книге( и он же, к слову, создатель JUnit)
оно и понятно: в контексте Agile unit-test-ы гораздо более ценны, потому что предполагается постоянный рефакторинг, а рефакторинг это как раз тот случай где unit-test-ы реально полезны.

но что прикольно: даже среди Agile евангелистов не все разделяют восторженное отношение к unit-test-ам (Dave Thomas : ~19:35 )
(Dave Thomas, кто не знает, один из тех 17-ти чуваков которые написали Manifesto for Agile Software Development)

вообщем, даже c распространением Agile, и развитием инструментария, не сказал бы я, что активно использовалось оно.
(в силу своей работы я регулярно сталкиваюсь со всяким legacy которое начинали писать до 2010 года и там тестов или вообще нет или нитожно мало)

я думаю, что реальный буст концепция получила с пришествием CI/CD: для CI/CD, unit-test из "полезно" превратились в "критически необходимо"

но в реальности: далеко не везде в проектах Agile(и слава богам) и CI/CD

несмотря на то, что лично я большой поклонник unit-test-ов, я признаю, что они нужны и оправданы очень не всегда(в особенности с 100% coverage)
и, к сожалению, элемент культа, вокруг них есть.
вчера, 16:24    [22334496]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
gmugar
1. это очень дорого: хорошие unit-test-ы и хорошее покрытие = +50% к бюджету проекта как минимум
Я пока не встречал проектов в которых модульные тесты замедляли их.. Они оттягивают перевод конкретной задачи в тестирование, но не сроки сдачи самого проекта. Я правда возможно по-другому пониманию "хорошим покрытием".
gmugar
далёкий от IT бизнес, по сей день, не понимает зачем это надо (сталкиваюсь постоянно)
Никогда этого не понимал.. Откуда бизнес вообще узнает про тесты. Это подноготная программиста, о них никому говорить явно не надо.
gmugar
оно и понятно: в контексте Agile unit-test-ы гораздо более ценны, потому что предполагается постоянный рефакторинг, а рефакторинг это как раз тот случай где unit-test-ы реально полезны.
Рефакторинг есть везде, не только в Agile. И сломать только что работающий функционал тоже можно везде. Не знаю почему бы модульные тесты были как-то связаны с Agile..
gmugar
несмотря на то, что лично я большой поклонник unit-test-ов, я признаю, что они нужны и оправданы очень не всегда(в особенности с 100% coverage)
Про 100% покрытие не спорю (речь же про line/branch coverage?). Но интересно когда модульные тесты будут не оправданы? Ну, кроме каких-то прототипов. Я на своей памяти не могу припомнить такой ситуации..
вчера, 18:00    [22334540]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование private методов  [new]
mayton
Member

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

1. это очень дорого: хорошие unit-test-ы и хорошее покрытие = +50% к бюджету проекта как минимум

Никто не ставит таких задач. Ни на одном проекте нам (к примеру) не заказывали процентовку покрытия. Это глупо.
Код - не одинаковый. Есть 20% особо важного кода, который представляет собой костяк логики. Его и надо
покрыть обязательно. Можное не 20. Можно 15 или 25 не суть важно. Главное что меньшая часть кода обладает
большим влиянием на качество продукта. Как по Паретто. А оставшиеся 80% это различного рода интеграции,
конфигурации, DSL языки и формальные процедуры оставшиеся от фреймворков. Их покрывать не нужно. Покрытие
особо ничего не даст а лишь усложнит поддержку тестов при эволюции.

Еще к пользе тестов я-бы добавил что они являют самую актуальную (!) документацию по использованию.
Реально! Актуальнее некуда. Никакой JavaDoc и Confluence не сравнится в точности. Читаем как книгу
тесты (сверху вниз) и озвучиваем что на наших глазах происходит. Если применять Scala или JBehave(Java) или
Spock(Groovy) то некоторые стейтменты можно писать на таком DSL что будет выглядеть как английски текст.
Бизнес-аналитики такое любят. Наглядно. И реально работает.
вчера, 19:56    [22334563]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5      [все]
Все форумы / Java Ответить