|
|
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mayton, авторВозможно ты - на зарплате и тебе безразлично, терпит убытки владелец ПО или нет. Но очень хорошим карьерным трамплином будет - приближение тебя самого к задачам и проблемам бизнеса. Если ты - чутко реагируешь на эти проблемы - то значит достоин повышения. Если тебе - безразлично то твоё повышение может быть по возрасту лет или там по внутренней аттестации я не знаю. В любом случае понимание рисков бизнеса и - страхование из сказанного следует один вывод - умеешь закрывать жопу - достоин повышения, и не важно во сколько это обходится бизнесу,.....тест прошел, значит жопа прикрыта и не важно сколько денег потрачено на составление, отладку, проверку теста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2021, 11:41 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
Пардон мы всё таки обсуждаем технические подходы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2021, 13:24 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mad_nazgul Во-о-от для этого тесты и пишут! Человек не может помнить всё. И лучше пусть упадут тесты, чем упадет прод. как прод то упадет)- падает тест ,его актуализируют и все,другой код не подвергается изменению в 99.9 % случаев тоесть если бы не было теста,то вообще ничего не упало бы и прекрасно работало. Опять же все эти тесты тупая ,голимая синтетика ,ты хоть обложись этими тестами с ног до головы- реальные баги как были ,так и будут и скорей всего в конторе,где разрабов шпуняют на эти тесты - багов будет в разы больше,так как времени на разработку остается меньше. И вообще не понятно как у вас сразу после пуша на прод чтоли идет поставка? обычно это некий релиз- перед которым идет несколько процессов- разработка- тестирование- пси и только потом прод тоесть после пуша и поставкой около 1.5 месяца всевозможных тестирований,смок ,регрес,нагрузочное итд и вот там как раз и отлавливается багулечка - процентов 70% ,остальное уже на реал юзерах в первые пару недель) и никакие тесты неспособны на это - тесты на данный момент в проектах,где есть QA отдел=ну такое себе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2021, 17:26 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mayton asv79 пропущено... Полнейшая хрень- никогда по тестам ты реально не поймешь что в коде происходит,ибо как ты выше заметил тесты обычно покрывают 20-30% Давно уже надо признать ,что тесты это ярмо- которое тянет на себе разраб,а вот зачем - большой вопрос Мой ответ - ну типо так принято,мы так привыкли,а вдруг на проде что то вылезет))ну какие то вообще не состоятельные пруфы,а бизнес за это платит Я не знаю как построена система взаимоотноешний у вас на проекте. Но у вас должно быть пристальное и внимательное отношение к ошибкам на проде. Возможно ты - на зарплате и тебе безразлично, терпит убытки владелец ПО или нет. Но очень хорошим карьерным трамплином будет - приближение тебя самого к задачам и проблемам бизнеса. Если ты - чутко реагируешь на эти проблемы - то значит достоин повышения. Если тебе - безразлично то твоё повышение может быть по возрасту лет или там по внутренней аттестации я не знаю. В любом случае понимание рисков бизнеса и - страхование от них это признак seniority. бизнес понимает как раз суть ,ибо сами прогеры- и поэтому у нас отличный QA отдел,а вот были места - где такого отдела по сути не было,зато заставляли писать тесты на каждый чих. Я не против тестов,пишу их ,но вижу их реальную бесполезность,особенно в рамках монолита,где я сейчас. Да на микросервисах тесты могли реально работать- ибо было много различных интеграций и как раз таки эти тесты и отлавливали все что поменяли в одном месте,но забыли поменять в другом) Но вот со стороны монолита это работает немного иначе - ну тоесть какой то помощи я почти за год от этих тестов не увидел,но зато ребята каждый день эти тесты правят хз зачем- я бы игнор навесил и забыл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2021, 17:36 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
asv79 как прод то упадет)- падает тест ,его актуализируют и все,другой код не подвергается изменению в 99.9 % случаев тоесть если бы не было теста,то вообще ничего не упало бы и прекрасно работало. Да легко. При интеграции. Тест упал, значит изменился контракт. (Если это unit-test) И вместо, например, строки прилетело число. asv79 Опять же все эти тесты тупая ,голимая синтетика ,ты хоть обложись этими тестами с ног до головы- реальные баги как были ,так и будут и скорей всего в конторе,где разрабов шпуняют на эти тесты - багов будет в разы больше,так как времени на разработку остается меньше. unit-test это инструмент разработчика. Unit-test пишут разработчики сами для себя. Остальным они особо и не нужны. Зачем они нужны разработчикам? Чтобы не помнить всё. Своего рода документация, причем которая актуализаируется by default. asv79 И вообще не понятно как у вас сразу после пуша на прод чтоли идет поставка? обычно это некий релиз- перед которым идет несколько процессов- разработка- тестирование- пси и только потом прод тоесть после пуша и поставкой около 1.5 месяца всевозможных тестирований,смок ,регрес,нагрузочное итд и вот там как раз и отлавливается багулечка - процентов 70% ,остальное уже на реал юзерах в первые пару недель) и никакие тесты неспособны на это - тесты на данный момент в проектах,где есть QA отдел=ну такое себе В системе человек-машина слабое звено это человек. Человек не может, в отличии от машины, одинаково эффективно делать одну и ту же операцию много раз подряд. Поэтому чем выше автоматизация тестирования, тем меньше вероятность пропустить баг. Интеграционное тестирование не может протестировать всё приложение. По банальной причине - комбинаторный взрыв. Т.е. либо тест будет длиться годами (пока пройдет по всем веткам ветвления) Либо тестируем что нам кажется важным, при этом не факт что это является действительно важным. Если вам не нравятся unit-test, то не пишите. Этот инструмент, не для вас (ну или вы не умеете им пользоваться). Так не надо себя мучить. Пишите как вам удобно. Потом в 12ч ночи ждите звонка когда прод упадет. <:o) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 07:19 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mad_nazgul asv79 как прод то упадет)- падает тест ,его актуализируют и все,другой код не подвергается изменению в 99.9 % случаев тоесть если бы не было теста,то вообще ничего не упало бы и прекрасно работало. Да легко. При интеграции. Тест упал, значит изменился контракт. (Если это unit-test) И вместо, например, строки прилетело число. Я конечно прошу прощения что вмешиваюсь, но что нужно сделать, чтобы "unit-test упал из-за изменения контракта" при одновременном соблюдении следующих условий: - мы тестируем вполне себе конкретный метод, со вполне себе конкретной сигнатурой - дизайн метода вполне себе "хороший", т.е. на вход он j.l.Object ни в каком виде не принимает, ровно как и не отдает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 08:17 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
Stanislav Bashkyrtsev gmugar1. это очень дорого: хорошие unit-test-ы и хорошее покрытие = +50% к бюджету проекта как минимум gmugarдалёкий от IT бизнес, по сей день, не понимает зачем это надо (сталкиваюсь постоянно)Никогда этого не понимал.. Откуда бизнес вообще узнает про тесты. Это подноготная программиста, о них никому говорить явно не надо. это про одно и тоже - про деньги. у проектов, знаете-ли, бывает бюджет. и время разработчика стоит очень дорого. увеличение бюджета даже на 20% ради unit-test = космические суммы; попробуйте обосновать эти траты - поймут далеко не все Stanislav Bashkyrtsev gmugarоно и понятно: в контексте Agile unit-test-ы гораздо более ценны, потому что предполагается постоянный рефакторинг, а рефакторинг это как раз тот случай где unit-test-ы реально полезны. постоянный рефакторинг есть далеко не везде. Stanislav Bashkyrtsev gmugarнесмотря на то, что лично я большой поклонник unit-test-ов, я признаю, что они нужны и оправданы очень не всегда(в особенности с 100% coverage) не оправданно всегда, когда затраты на тесты и их поддержку не приносят хоть какой-то ощутимой пользы понять где эта граница полезности не всегда легко, да отсюда и проистекают рекомендации о том, что не надо покрывать unit-test-ами (ищите в интернетах, таких статей, больших и интересных, много "What should you not test") ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 09:11 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
gmugarэто про одно и тоже - про деньги. у проектов, знаете-ли, бывает бюджет. и время разработчика стоит очень дорого. увеличение бюджета даже на 20% ради unit-test = космические суммы; попробуйте обосновать эти траты - поймут далеко не всеДак откуда бизнес вообще узнает про это? Ни на одном проекте у меня бизнес сам не спрашивал "а сколько времени вы тратите на модульное тестирование". Они и знать-то не знают что такое существуют. Мы же об этом им не говорим, как не говорим и про рефакторинги и прочие технические детали. Им это не интересно. Они просто радуются результату. gmugar Stanislav Bashkyrtsev пропущено... Рефакторинг есть везде, не только в Agile. И сломать только что работающий функционал тоже можно везде. Не знаю почему бы модульные тесты были как-то связаны с Agile.. gmugar Stanislav Bashkyrtsev пропущено... Про 100% покрытие не спорю (речь же про line/branch coverage?). Но интересно когда модульные тесты будут не оправданы? Ну, кроме каких-то прототипов. Я на своей памяти не могу припомнить такой ситуации.. не оправданно всегда, когда затраты на тесты и их поддержку не приносят хоть какой-то ощутимой пользыЯ попросил конкретный пример.. Сам я таких таких ситуаций не помню. Есть вещи которые сложно тестировать (генерация PDF), на них часто забивают. Но чтоб вообще не писать тесты на проекте и это бы ускоряло разработку - такого не встречал. Андрей Панфилов mad_nazgul пропущено... Да легко. При интеграции. Тест упал, значит изменился контракт. (Если это unit-test) И вместо, например, строки прилетело число. Я конечно прошу прощения что вмешиваюсь, но что нужно сделать, чтобы "unit-test упал из-за изменения контракта" при одновременном соблюдении следующих условий: - мы тестируем вполне себе конкретный метод, со вполне себе конкретной сигнатурой - дизайн метода вполне себе "хороший", т.е. на вход он j.l.Object ни в каком виде не принимает, ровно как и не отдает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 09:43 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
asv79 бизнес понимает как раз суть ,ибо сами прогеры- и поэтому у нас отличный QA отдел,а вот были места - где такого отдела по сути не было,зато заставляли писать тесты на каждый чих. Я не против тестов,пишу их ,но вижу их реальную бесполезность,особенно в рамках монолита,где я сейчас. Да на микросервисах тесты могли реально работать- ибо было много различных интеграций и как раз таки эти тесты и отлавливали все что поменяли в одном месте,но забыли поменять в другом) Но вот со стороны монолита это работает немного иначе - ну тоесть какой то помощи я почти за год от этих тестов не увидел,но зато ребята каждый день эти тесты правят хз зачем- я бы игнор навесил и забыл Стас дружище. Вот ты уже раз 10 повторил один и тот же стейтмент о том что видишь реальную бесполезность тестов. Ты говорил об этом со своим техническим лидом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 12:07 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mayton Ты говорил об этом со своим техническим лидом? ".. врач сказал: "в морг". значит в морг...." mayton Пардон мы всё таки обсуждаем технические подходы. тесты сделал, - "..К пуговицам претензии есть?..", и не важно как костюмчик сидит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 13:03 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mayton asv79 ... Но вот со стороны монолита это работает немного иначе - ну тоесть какой то помощи я почти за год от этих тестов не увидел,но зато ребята каждый день эти тесты правят хз зачем- я бы игнор навесил и забыл Стас дружище. Вот ты уже раз 10 повторил один и тот же стейтмент о том что видишь реальную бесполезность тестов. Во многих случаях (тестирование логики в БД, тестирование не модульно созданного монолита, тестирование при постоянной разработке и меняющихся требованиях и так далее) можно говорить, что тесты и их поддержание в актуальном состоянии очень дорого. Но говорить, что они бесполезны... Х.з.... видел многие проекты где необходимых тестов не было, именно из-за их дороговизны (или кривизны рук, не смогли малыми силами сделать тесты)... но говорить о бесполезности - пытались, полезность была всем понятна, но просто не смогли сделать ((( Ручное тестирование - не является альтернативой. Для нового функционала, да, конечно. Но с точки зрения регрессион тестов - ручное тестирование просто не реально. IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 13:43 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
вадя тесты сделал, - "..К пуговицам претензии есть?..", и не важно как костюмчик сидит. IMHO & AFAIK вообще-то тесты (план тестирования) должны делать не столько программисты, сколько аналитики/консультанты. Есть ТЗ, требования - вместе с ним должен быть базовый/начальный план тестирования. По крайне мере по Oracle AIM ровно так. Без относительно ручные/автоматические тесты. Unit Test'ы обычно пишут сами программисты. Но если мы хотим от тестов еще и ценности для бизнеса - то нужно ориентироваться все же на план тестирования, который должен возникать НЕ при программирование, а значительно раньше. Граница между Unit / интеграционные и так далее - IMHO для монолита не очень очевидна. Для многих типов монолитов вообще Unit тест не возможен (логика в бд, MS Acess, FoxPro и так далее) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 13:49 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
вадя mayton Ты говорил об этом со своим техническим лидом? ".. врач сказал: "в морг". значит в морг...." mayton Пардон мы всё таки обсуждаем технические подходы. тесты сделал, - "..К пуговицам претензии есть?..", и не важно как костюмчик сидит. Давай подойдем с другой стороны к вопросу. Не с про-активной а с реактивной. Вот допустим сделан релиз. И был зафиксирован к примеру 5 критических багов и 3 основных и 2 минорных. Надо проанализировать ситуацию. И понять как так случилось что 5 багов было пропущено? Если это были кейсы которые было принпиципльно НЕВОЗМОЖНО протестировать (баг на стороне БД) или вообще проблема сетевой инфраструктуры или кто-то завтыкал ключи и пароли обновить - то это просто будет зафиксировано как неизбежность. Но если был шанс поймать это тестированием чистой бизнес-функции - то после фиксации такие тесты надо написать. И обобщить этот approach на всё приложение. Посмотреть где в подобных местах может случится следующий баг. Придавить тестами. Вот как-то так. Итеративно. И это покрытие уже будет покрывать не инварианты где тестят что 1==1 и не пустышки про которые так ругается Стас а реально, боевой и значимый код. И вот этот боевой код должен быть компактным. Я ванговал 20% но я готов согласится и на меньшее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 14:45 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mayton Не специалист по ISO 9000 Но вроде ISO 9000 не требует, что бы ошибок не было. Но требует (!), что бы если ошибка/проблема была выявлена, то были приняты организационные меры, что бы такая ошибка/проблема (а лучше целый класс проблем такого рода) не могла повториться в дальнейшем Тесты и должны давать такую возможность. Если баг выявили, то должен быть тест, гарантирующий что такой баг не будет повторен. Но это в теории. А на практике, например в Oracle СУБД, дофига багов которые были устранены в 11.4, а в 11.5 уже обратно появились один в один ((( Как так? ((( И не сказать, что Oracle маленькая контора, и не сказать, что у них бюджен на разработку СУБД (основного продукта) маленький.... а те же самые баги по несколько раз всплывают ((( и где тесты ((( и где качество ((( AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 15:14 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mayton Стас дружище. Вот ты уже раз 10 повторил один и тот же стейтмент о том что видишь реальную бесполезность тестов. Ты говорил об этом со своим техническим лидом? Конечно,он топил за TDD вообще,кое как удалось его убедить ,что в рамках растущего на как на дрожжах проекта - такая концепция просто непременима .Сошлись с ним на интерагционных и унит тестах и я наверно первый кто написал какое то огромное количество тестов тогда,потом его слава богу уволили и тема тестов благополучно сошла на нет.Но до сих пор я вижу ,как о те тесты постоянно спотыкаются разрабы при разработке и рефакторинге- тратится уйма времени на их актуализацию ,а это все деньги и достаточно ощутимые. Я не умаляю роли тестов,но как выше уже говорил на монолитах наверно они просто бессмыслены. На интеграциионных,когда вы разрабатываете несколькими командами что то микросервисное - там да они нужны с натяжкой вот ПРимер когда тесты нужны миросервисная архитектура брокер сообщений - например кафка есть некий микросервис выступающий источником правды для всех остальных сервисов- тоесть в нем лежат дтошки,которыми сервисы кидаются в друг друга и вот когда ты обновил свой сервис и сервис с дтохами - другой сервис об этом не знает ,но как только будут запушены интеграционные тесты - упадет- тем самым и достигается польза- разраб второго сервиса пойдет акутализировать свой код! именно код,а не тест- вот тут польза от тестов просто колосальная - так как если у вас достаточно большой зоопарк никаких тестировщиков не хватит все это потестить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 18:32 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
asv79 и вот когда ты обновил свой сервис и сервис с дтохами - другой сервис об этом не знает ,но как только будут запушены интеграционные тесты - упадет- тем самым и достигается польза- разраб второго сервиса пойдет акутализировать свой код! именно код,а не тест- вот тут польза от тестов просто колосальная - так как если у вас достаточно большой зоопарк никаких тестировщиков не хватит все это потестить Ну это ближе к интеграционным. Ведь вам надо по сути проверить что контракт сошёлся. Дернули метод и он ответил - Http-200 OK! Кстати при зоопарке микросервисов - полезно создавать 1 общий репо куда складывать декларации сетевых протоколов в: - Swagger - GraphQl - SOAP - e.t.c. Как только кто-то обновился - все другие команды обязаны зайти и синхронизировать клиентов (или серверы кому как надо). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 20:56 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mayton Вот допустим сделан релиз. И был зафиксирован к примеру 5 критических багов и 3 основных и 2 минорных. Надо проанализировать ситуацию. И понять как так случилось что 5 багов было пропущено? Если это были кейсы которые было принпиципльно НЕВОЗМОЖНО протестировать (баг на стороне БД) или вообще проблема сетевой инфраструктуры или кто-то завтыкал ключи и пароли обновить - то это просто будет зафиксировано как неизбежность. Но если был шанс поймать это тестированием чистой бизнес-функции - то после фиксации такие тесты надо написать. И обобщить этот approach на всё приложение. Посмотреть где в подобных местах может случится следующий баг. Придавить тестами. авторНо если был шанс пойматьа где вероятность , что затраты на это тестирование окупились? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 21:05 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
Эту вероятность никто не посчитает. Сам оценишь. Если следующий релиз пройдет без багов - значит было успешно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 21:09 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
mayton Эту вероятность никто не посчитает. Сам оценишь. Если следующий релиз пройдет без багов - значит было успешно. и появятся новые.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 21:10 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
вадя mayton Эту вероятность никто не посчитает. Сам оценишь. Если следующий релиз пройдет без багов - значит было успешно. и появятся новые.... А у тебя - серебрянная пуля есть? Или знаешь куда "соломки" подложить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2021, 21:16 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
НУ вот у меня сейчас есть план протестировать рест+ кафку+дб тоесть на вход я должен скормить джейсон -отправить его на наш рест - отуда послать в топик кафки - из топика достать ,записать в бд и проверить что я записал то,что я отправил в джейсон такого просто нет . везде будет одна синтетика- например кафку вообще никак не затестить - нужно юзать Embded а там уже не те настройки совершенно----------другие смысл тогда ее тестировать? если по факту будет тест не твоей кафки ,а какой то искуственной херни,которую ты ток что в тесте и создал и будешь ее же тестировать лол базу данных тестировать - нужно отельный класс рисовать - а если я хочу сразу на вход теста положить джейсон а на выходе достать запись из бд- такого нет нифига -есть воообщем и целом как я и говорил - проще руками проверить чем вот тратить время на эти велосипеды,так как внятного инструмента я не нашел чтобы такое осуществить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2021, 17:35 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
asv79 НУ вот у меня сейчас есть план протестировать рест+ кафку+дб Не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2021, 19:19 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
asv79 НУ вот у меня сейчас есть план протестировать рест+ кафку+дб тоесть на вход я должен скормить джейсон -отправить его на наш рест - отуда послать в топик кафки - из топика достать ,записать в бд и проверить что я записал то,что я отправил в джейсон такого просто нет . везде будет одна синтетика- например кафку вообще никак не затестить - нужно юзать Embded а там уже не те настройки совершенно----------другие смысл тогда ее тестировать? если по факту будет тест не твоей кафки ,а какой то искуственной херни,которую ты ток что в тесте и создал и будешь ее же тестировать лол базу данных тестировать - нужно отельный класс рисовать - а если я хочу сразу на вход теста положить джейсон а на выходе достать запись из бд- такого нет нифига -есть воообщем и целом как я и говорил - проще руками проверить чем вот тратить время на эти велосипеды,так как внятного инструмента я не нашел чтобы такое осуществить То что вы описываете больше похоже на end2end тест. например кафку вообще никак не затестить - https://www.testcontainers.org/modules/kafka/ Там же можно и бд развернуть Но это в любом случае уже не unit-тест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2021, 19:22 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
нормальный тест был бы такой запускается локально инстанс приложения с докер контейнером зависимостей там инстанцируются БД,кафка и прочие нужности и далее тест шлет на локал хост /енд поинт некий джейсон ,этот джейсон собирается в объект и отсылается в кафка топик далее листенер видит саюж->пишщет его в базу и проверяет записалась ли такая запись в бд вот это был бы реально нормальный тест,а не вот эта вся резиновая мандула-> хочешь кафку тестить - ага -ну создай новую встроеную) а шо она тестирует - ну сама себя)) и вот с этими тестами по факту всегда так - тупо голимая синтетика для тестирования самой себя в моем кейсе нет вариков как все это протестировать- только тупо руками или создать еще одно приложение,котрое будет тестировать другое ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2021, 19:26 |
|
||
|
Тестирование private методов
|
|||
|---|---|---|---|
|
#18+
asv79 нормальный тест был бы такой запускается локально инстанс приложения с докер контейнером зависимостей там инстанцируются БД,кафка и прочие нужности и далее тест шлет на локал хост /енд поинт некий джейсон ,этот джейсон собирается в объект и отсылается в кафка топик далее листенер видит саюж->пишщет его в базу Так а в чем проблема сделать такой тест? просто это не unit-тест, а что-то выше в пирамиде тестирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2021, 19:27 |
|
||
|
|
start [/forum/topic.php?fid=59&startmsg=40077470&tid=2120410]: |
0ms |
get settings: |
22ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
545ms |
get tp. blocked users: |
2ms |
| others: | 440ms |
| total: | 1091ms |
| 0 / 0 |
