у него NH

О, этот течёт

хз, уже лет 5 дотнетами не обмазываюсь потому не шарю...

хз, уже лет 5 дотнетами не обмазываюсь потому не шарю...

Ну у нас православные - это EF Core, Dapper и Linq2db

а для тех, кто не знает что написано на какой-то странице xunit'а: зачем аще в тестах в базу писать?) Похер в какую (инмемори, или вполне настоящую) проверить, что инмемори база работает? или оракл потестить?)

Проверить код который связан с базой напрямую

Но тут вполне достаточно мокнуть базу

не вижу связи между кодом и базой

Но тут вполне достаточно мокнуть базу

вот. так связь где?)

вот. так связь где?)

вопрос что ты хочешь проверить... мне вот кажется что интеграционные тесты с in memory хранилищами немного.... неудобны

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

короч я за e2e

вопрос что ты хочешь проверить... мне вот кажется что интеграционные тесты с in memory хранилищами немного.... неудобны

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

тебе не надо его тестить, тебе надо подсунуть данные

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

обычно это простые кейсы довольно

Mocks

Это натуральная подмена имплементации кода филлером для тестов

тебе не надо его тестить, тебе надо подсунуть данные

о том и речь) почему тут учавствуют слова типа стораджей (вполне себе реальных)

Так как мы исходим из предпосылки, что мы не тестируем работу самой бд, то так получается наиболее оптимально, так как код считает что работает с реальной базой

а для тех, кто не знает что написано на какой-то странице xunit'а: зачем аще в тестах в базу писать?) Похер в какую (инмемори, или вполне настоящую) проверить, что инмемори база работает? или оракл потестить?)

не засорять живую базу ненужными записями

не засорять живую базу ненужными записями

код аще не должен ни в какую базу ползать. Ни в живую, ни в тестовую

код аще не должен ни в какую базу ползать. Ни в живую, ни в тестовую

такое ощущение что мы разговаривам сейчас о разных вещах

такое ощущение что мы разговаривам сейчас о разных вещах

такое ощущение, что кто-то не очень понимает что и зачем он пытается тестировать

не засорять живую базу ненужными записями

Максим тебе предлагает тестовую базу поднять

и я с ним согласен, если есть такая возможность лучше так

код аще не должен ни в какую базу ползать. Ни в живую, ни в тестовую

должен

увы

такова природа приложений которые мы разрабатываем и интеграционных тестов

Максим тебе предлагает тестовую базу поднять

да не) максим предлагает аще базу не подменять, а мокнуть интерфейс. мне нахер не надо тестировать работу базы. Она работает гарантированно лучше моего кода

да не) максим предлагает аще базу не подменять, а мокнуть интерфейс. мне нахер не надо тестировать работу базы. Она работает гарантированно лучше моего кода

ну это к вопросу что интеграционные тесты не очень то и нужны)

ну это к вопросу что интеграционные тесты не очень то и нужны)

а что у тебя тестируют интеграционные тесты?) запись в оракл?)

а что у тебя тестируют интеграционные тесты?) запись в оракл?)

у меня?))

у меня?))

ну ты говоришь, что реальная база нужна (копия). Зачем?)

у меня есть куча фигни которой нужны данные на чтение

и я не могу это юнитами покрыть

ну точнее могу но толку....

а вот позитивный интеграционный тест покроет большую часть этого кода

и для этих штук я делаю e2e тест где поднята вообще вся инфраструктура

база данных, кролики, эластика, рэдисы... полный фарш

20-30 сценариев позитивных, просто что бы убедиться что система в целом работает, и ном

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

остальное покрывается юнитами

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

мне кажется, всё сильно проще

но столько времени убить и до сих пор не сделать - это как по мне звоночек

ну короч, это ж @hell_boy_19811

что ты от него хочешь

признаки мозгов) #онжепрограммист)

он "рефакторил что бы его уволили"...

я до сих пор не понимаю этой логики

я до сих пор не понимаю этой логики

ich habe diese Firma als Übergangsphase benutzt. Bei Firma ging es um sehr hohe technische Schulden von ehemaligen Entwickler, der ohne Framework programmiert. Ich war zwar während VG gewarnt, aber Angebot akzeptiert um für mich finanzielle Nachteile zu vermeiden. Jetzt habe ich endlich bei Ihnen gelandet. немцы прекрасно все понимают

я все еще не понимаю как написанное тобой привело к необходимости рефакторить простой код в говно на 10K строк?

то что можно в уши нассать и сказать "они плохие" - это все умеют

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

я все еще не понимаю как написанное тобой привело к необходимости рефакторить простой код в говно на 10K строк?

отрабатывал зарплату

отрабатывал зарплату

сделать плохо за чужие деньги, это не отрабатывал, это проебал

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

ещё если учесть, скок времени на это было просрано... как по мне, прикрывать низкую квалификацию плохими заказчиками - такое себе.

я больше думаю что тут не в квалификации вопрос а в том, что движет человеком.... не проблему решать а паттернами обмазываться

паттерны ради паттернов - это как раз следствие опыта, имхо

не вижу связи между кодом и базой

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

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

Подстановка инмемори стораджа мало чем отличается от копии

И конечно это все интеграционные тесты, а юнит тестами их называют потому что эти данные не живут между сессиями тестов, ну или что-то такое)

Подстановка инмемори стораджа мало чем отличается от копии

Отличается ? Это дешевле делать и быстрее работает

Но может от стека это разнится чуток, но суть та же

Отличается ? Это дешевле делать и быстрее работает

Да нифига) действия ровно те же самые)

Ин мемори может быть сложнее, если репозиторий хитрый

Отличается ? Это дешевле делать и быстрее работает

Чем проще-то в твоей картине мира?

1. Install dependency 2. Swap connection string

Не очень похоже на ответ)

Не очень похоже на ответ)

Нет явной работы с хранилищем

Нет явной работы с хранилищем

И?) Развивай мысль

У тебя есть явная работа с хранилищем. Вот в чем фокус) Помимо всего прочего, как выше Aleh сказал, ловишь ещё кучу сюрпризов. Так чем проще-то? Отсутствием коннекта? Да насрать на него. Расходы на создание схемы? Можно принебречь, они разовые

У тебя есть явная работа с хранилищем. Вот в чем фокус) Помимо всего прочего, как выше Aleh сказал, ловишь ещё кучу сюрпризов. Так чем проще-то? Отсутствием коннекта? Да насрать на него. Расходы на создание схемы? Можно принебречь, они разовые

Я имел ввиду что не надо руками поднимать бд, очищать между тестами и тп

Я имел ввиду что не надо руками поднимать бд, очищать между тестами и тп

Это имеет смысл только на тысячах тестов, которые активно дрючпт бд. А такое не часто встречается.

Просто по тому, что не все тесты а целом с бд работают. Похер какой

Я не фанат базы в тестах) но если писать нормальные функциональные тесты, то делать это на копии.

Это имеет смысл только на тысячах тестов, которые активно дрючпт бд. А такое не часто встречается.

Ну я не говорю что это хорошо, я говорю что это позволяет тестировать без сайд эфектов почти любой сильно связанный (coupling) код с минимальными усилиями. Что мешает людям серьёзней относится к архитектуре

Связанность тут не особо подходит. Как раз говнокодище проще тестить на копии. Не придётся палки подставлять, что бы закрывать все моменты в кривом интерфейсе.

Связанность тут не особо подходит. Как раз говнокодище проще тестить на копии. Не придётся палки подставлять, что бы закрывать все моменты в кривом интерфейсе.

как раз таки связанность тут и решает. Код с высокой связанностью ты юнитами никак не покроешь

как раз таки связанность тут и решает. Код с высокой связанностью ты юнитами никак не покроешь

Как мне в этом поможет тип стораджа?)

более того, возможность покрыть юнитами можно использовать как метрику связанности)

Как мне в этом поможет тип стораджа?)

никак)))

ну то есть тебе поможет persistence ignorance

никак)))

Ч.т.д)

ну то есть тебе поможет persistence ignorance

Вопрос изначально стоял не в качестве кода как такового, а что с помощью инмемори легче легаси тестировать. Вот пытаюсь понять, с чего вдруг легче-то

ну смотри...

хотя...

не, не смотри... тоже не понимаю

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

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

Вооот

по поводу "тесты быстрее" - я запускаю postgresql в tmpfs для тестов - работает раза в 2 быстрее чем просто

Об оракл руки не пачкал, но, думаю, его в оперативку запихнуть тоже не биг дил

нууу... хэзээээ

это те не постгрес

Быстрый вопрос к гуглу отвёл прям на оф доку)

там докер образ вроде весил 2-3 гига

там докер образ вроде весил 2-3 гига

вся винда в комплекте :D

Хз. Я даже мимо оракла не проходил. У нас был дба, были громадные планы по миграции.. но планы улетели в мусорку вместе с дба)