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