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

Откуда: Тверь
Сообщений: 3329
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

Откуда: Тверь
Сообщений: 3329
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

Откуда: Тверь
Сообщений: 3329
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

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

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

Откуда: Тверь
Сообщений: 3329
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

Откуда:
Сообщений: 5688
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

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


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

Откуда: СПб
Сообщений: 142
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

Откуда:
Сообщений: 5688
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

Откуда: СПб
Сообщений: 142
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

Откуда: СПб
Сообщений: 142
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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Java Ответить