Ваш донат это 1001ая причина на вас наехать. Если наезд со стороны органов случится, то не потому, что вы донатили, а потому, что вы оказались в ненужном месте в ненужное время. А причина, по которой вас посадят может быть произвольной. Донат, неправильная расцветка одежды (привет Беларусь), оскорбление сотрудника мыслью, причинение испуга бумажным стаканчиком, участие в выдуманной майором организации, педофилия и так далее.
Если вы настолько обеспокоены безопасностью, то не смотрите youtube (продвижение экстремистской организации путём влияния на алгоритмы YouTube с помощью просмотра), не читайте посты где есть слова УГ, Навальный и т.п., не пишите ничего онлайн, станьте членом Единой России.
Вы, кажется, не прочитали мой комментарий и отвечаете на что-то придуманной вами. Я повторюсь
Форма подачи и попытка завуалировать все это под "помощь" выглядят максимально отвратительно.
Про то, что пентест это плохо или хорошо я ничего не писал. А вот о том, что раскрытие уязвимостей без какой-либо внятной попытки связаться, это да, об этом я писал.
Вы полагаете, что оригинальный комментарий предполагал потворство дырам в безопасности? Ну ОК. Кажется тут даже ребенку понятно, что дыры это плохо, а комментатор говорит о том, что действительно важно.
Этот пост очевидная атака на проект Навального и Волкова лично. У кого-то есть нездоровое желание публиковать проблемы сайта, ну пожалуйста. Форма подачи и попытка завуалировать все это под "помощь" выглядят максимально отвратительно. Я бы автору порекомендовал переключиться на kremlin.ru.
На этом шаге хочется остановиться, ведь не стоит цель навредить,
Как-то не похоже... Хватило ума и таланта найти дыру, но написать в твиттер Волкову что-то вроде "У вас дыра, я покажу, пишите в личку" нет?
Вот вам предложение - поковыряйте сайты типа kremlin.ru, ФСБ и т.п., а затем напишите тут о дырах. После этого посмотрим насколько круто изменится ваша жизнь. Если платформа Волкова имеет под собой основания, то мы о вас тут какое-то время не услышим. Я лично буду рад, если на хабре таких желчных постов будет меньше.
Защита от брутфорса, DDOS, инжекций, format string, переполения буфера, фильтрация технической информации в сообщениях об ошибках и еще 1024 возможных атаки вы не рассматриватете? Или по вашему все это можно просто привинтить без адских костылей в виде отдельного модуля к системе, в которой защита не закладывалась на уровне дизайна?
Именно так, если вы используете нормальный фреймворк, то все это у вас уже есть, осталось включить в конфиге. Скорее всего не будет защиты от DDoS, но тут вам помогут облака и/или cloudflare. Если же у вас нет фреймворка и вы все написани на чистом C, то вам поможет AWS API GW. Хотя тут, конечно, вопросы будут к SQL injection и аналогам, то есть ошибкам и небрежностям в кодировании.
Мне не очень понятно что означает "закладывать защиту на уровне дизайна". Защита это аспект, которые все известные мне среды разработки стараются максимально отделить от бизнес логики. Потому и включается все это в конфиге или подключением модулей/библиотек.
И не найдут, потому что не надо все переделывать. Непонятно как вообще надо сделать систему, чтобы в неё нельзя было добавить авторизацию. В каждом фреймворке это есть, что надо было сделать, чтобы нельзя было просто включить встроенную функцию?
>Или это всё-таки фреймворки/технологии, а именно решение мне надо будет писать самому?
Процитирую самого себя
>Обработка событий, которые возникают в рамках интеграции может быть произвольно сложной, но это и есть бизнес логика, которую никто за вас не напишет.
Да, вам нужно собрать решение и часто нужно для этого писать код.
Предположить можно. Есть только одна проблема. А именно что это будет в корне неверное предположение :)
Тогда возникает сомнение, что это типовое решение... Ну в самом деле, типовое решение, которое не решает типовые проблемы, это очень странно.
Хм. Мы сейчас о реальном мире говорим или о том как оно должно было бы выглядеть в теории? Как минимум в моей реальности ситуация выглядит так что предложения из коробки берут в основном из-за начальной дешивизны. Не особо задумываясь о будущем.
Вот тут совсем непонятно. Как может типовое решение быть хуже самопала для типичного использования? Понятно, что оно дешевле, потому что продается на потоке. Но оно еще может быть и лучше, потому что в него денег вливается предположительно сильно больше, чем покупатель может себе позволить.
Либо конкретно такое решение нужно не такому уж большому количеству людей. И поэтому никто не заморачивается типовым решением. Но конечно я могу и ошибаться. И где-то существует это самое типовое решение для интеграции с Nagel-Group. Не подскажете где?
AWS SNS/Lambda/Step Functions + C# не поможет? Возможно есть что-то более специализированное и тогда следует взять это решение, при прочих равных.
Если заказчик сидел на типовом решении, то можно предположить, что интеграции с компаниями типа Nagel-Group для пользователей этого решения не редкость. Не обязательно конкретно Nagel-Group, не обязательно именно такая интеграция какую вы в итоге сделали. Но следует ожидать, что у пользователей коробки проблемы примерно одинаковые и решения тоже. Тогда должно получаться, что как только пользователь коробки дорос до Nagel-Group, то все, баста, приехали. Опытный интегратор об этих ограничениях должен знать, а неопытный провести достаточно исследований чтобы распознать.
Я думаю, что на самом деле происходит не так. А сначала интегратор, который плохо понимает платформу и учится по ходу, лепит решение, а затем оказывается, что оно плохое. Либо типовое решение изначально было выбрано неверное. Либо компания переросла это решение, как Washington Post перерос WordPress. В любом случае, кроме первого, все нормально, типовые решения не обязаны быть абсолютно универсальными.
А вот первый случай это пример непрофессионализма и защищать его не стоит. Также непрофессионально (и вредно для доходов) впаривать кастомное решение заказчику, который явно требует типовое решение. Я полагаю, что проблема автора статьи в том, что имея в руках Java/C#/PHP все кажется кастомной программой. Не имея опыта в конкретной области заказчика ему впихивают ненужное решение, а он сопротивляется. И все это выдается как поучительная история о том, какие заказчики дебилы.
Возвращаясь к дихотомии Washington Post - WordPress мне хочется вам задать вопрос. WordPress не подходит крупной газете (как минимум) из-за размеров организации, штата редакторов, продажи рекламы и всяких процессов которые с этим связаны и требуют автоматизации. В WordPress я могу указать на массу функций, которых в нем просто нет и обосновать, что добавлять все это в него сложнее, чем писать систему с нуля. А в чем был фатальный недостаток того типового решения, которое вы заменяли?
Не думаю, что есть такие заказчики, которые хотят самое дешевое решение несмотря ни на что. Заказчик обычно ищет оптимальное соотношение цена-качество. Моя проблема со всеми фреймворками ровно в том, что заказчика чаще всего вводят в заблуждение касательно реальной стоимости разработки, а главное поддержки этого агрегата. Если бы заказчику сразу сказали, тебе теперь нужна команда из 3х человек и ФОТ для них в 12 млн в год, то он бы очень сильно подумал о нетиповых хотелках.
Ну расскажите мне про фреймворк который имеет готовое типовое решение для полноценной интеграции вашего магазина или там системы логистики в системы амазона. Про интергацию с какими-нибудь Rewe/Aldi/Metro или Nagel-Group я вообще молчу.
Если получив задачу интеграции с Rewe/Aldi/Metro или Nagel-Group вы 2 месяца тратите на фреймворк для интеграций, то вы точно что-то делаете не так. Обработка событий, которые возникают в рамках интеграции может быть произвольно сложной, но это и есть бизнес логика, которую никто за вас не напишет. Штуки вроде доставки сообщений, их хранение, повтор в случае ошибки, всякие панели управления и мониторинги, оркестрация разных сервисов, все это давно решено. То есть получив задачу на интеграцию будет правильно просто сделать интеграцию, а не разрабатывать фреймворк для описания интеграций.
Вот смотрите
К нам обратилась компания, которой была нужна система, предполагающая некоторое взаимодействие между пользователями разных ролей. Функционала было много, развивать платформу предполагалось итерационно.
Выглядит как типовая задача - бизнес процесс надо организовать, есть миллион решений, но сразу же речь идет о "платформе". Задача о взаимодействии разных ролей стара как персональный компьютер. Игнорировать последние 30 лет развития и писать свою платформу для этого глупо. Заказчик не дурак, он то понимает, что что-то идет не так и сопротивляется.
Ваша проблема же не в том, что заказчик не понимает размеры морковки. А в том, что он как раз понимает, что его дурят. Он хочет от вас типовое решение, как в миллионах других проектах, а вы ему продаёте месяц разработки, словно у вас нет никаких наработок.
С языка сняли. Заказчик точно хочет типовое решение, а ему продают уникальный предмет искусства ручной работы. Причём это похоже на бизнес заказчика, область, в которой уже давно сделали все возможные фреймворки, но ему продают очередной такой фреймворк, видимо чтобы он побольше страдал в будущем.
Я не понимаю зачем вы придумываете высказывания, приписываете их мне и комментируете… но мне точно не интересно в эти игры играть. Мне интересно другое - я пытаюсь вашу позицию понять. Про электриков я все понял, а также про то, что разные бывают виды оплаты труда. Но я тут говорю о вполне конкретной ситуации, она на практике постоянно встречается - задачи в беклоге не кончаются. И мне интересно, как вы в такой ситуации будете работать. Если ответ - 4 часа потому что платят 5 копеек, то пусть так и будет. Просто хочется ясности.
Мнение понятно отчего при разговоре о DDD всплывает постоянно Event Sourcing? Когда речь заходит про event sourcing нужно всегда уточнять, что правильно его реализовать очень сложно и дорого. Потому что все должно быть 100% детерминированно.
У вас где-то concurrent ordered map, скорее всего там skip list и рандом внутри. А значит порядок обхода этой коллекции будет разным при каждом запуске.
DateTime.Now, очевидно.
Настройки системы, например дефолтный часовой пояс.
Настройки самой программы. Типа размер кеша.
Можно поискать в блоге LMAX рассказы о том, как они решают эти проблемы. Это долго, дорого и больно. Не надо event sourcing если у вас не high load и не сложная in-memory модель (обычно это из-за требований к latency) короче если вы не делаете биржу или мультиплеер в реальном времени это не ваше.
>>>>Неа. В договоре написано про 8 часов день + 1 час на обед. Вот я продаю это время, а не продуктивность 40 часов в неделю весь год, за исключением отпуска.
>>>Оклад — продажа решения задач основных. В данном случае — нахождения на работе и чтоб в этот момент при появления задач вы их делали по какой-то «усреднённой» производительности.
>> ... прилагать максимально возможный уровень усилий, который позволит вам продолжать эту деятельность, без падения продуктивности, до выхода на пенсию.
>Оклад — тогда озвучивайте производительность, выше которой я не обязан прыгать.
Озвучил - "прилагать максимально возможный уровень усилий, который позволит продолжать деятельность, без падения продуктивности, до выхода на пенсию." Добавлю - это и есть определение "продуктивного времени", с которого все началось.
Звучит интересно, я теоретизировал на эту тему, но до практики не дошло. Расскажите больше. Тесты пишет архитектор, а заставляют их работать программисты? Тесты на все или только на АПИ? Как изолируется окружение типа БД и прочие зависимости, которые сложно замокать?
Я просто показываю пример одинакового объема работы за одно время за одну сумму и у вас уже не бьется, как так, кто-то смеет оставшиеся 4 часа не работать
Как он может не работать, если есть прямая инструкция брать следующую задачу из беклога? Если он так делает, то нарушает договоренности и это как раз и есть тот обман, с которого все началось.
как так, кто-то смеет оставшиеся 4 часа не работать
Конечно, я же так похож на карикатурного буржуя-эксплуататора из советских агиток.
Тут уже привели где-то недавно ссылки на статью про три основных варианта за что платит работодатель.
Разные работодатели платят за разные вещи, а скорость света в вакууме есть константа, какие ещё очевидные факты нам нужно прояснить? На самом деле мне просто интересно, что вы будете делать если получите прямую инструкцию работать 8 часов в день, выбирая задачи из бесконечного беклога. Будете ли вы осознанно саботировать процесс, мотивируя это тем, что платят мало или, что Вася в 2 раза медленнее работает, а получает столько же. Или просто будете работать?
В качестве примера силы TDD вы привели приложение, которое было создано в 2016 году, а первый тест у него появился в 2018. Вот это test first!
О!!!! так вы же и автор, и после этого вы мне за TDD втираете?
Ну все, вы меня свалили своими аргументами, валяюсь под столом. Я уверовал, что TDD без моков возможно - это когда сначала код, а затем тесты, и тесты гоняют реальное приложение со всей инфраструктурой. Если кто-то назовет это функциональным, интеграционным или acceptance тестом, то мы его вместе выследим и заставим извиниться на камеру за такую ересь. Спасибо, что открыли глаза.
Удобно, я вам даю набор предикатов и чтобы все расставить по местам достаточно показать, что один из них неверен, не стоит ради этого такие сочинения писать.
Локализованностью конкретного функционала.
Вы сравниваете public User FindById() с public static User FindById(this DbContext db). Какая тут разница в локализации функционала?
4) Кроме того, даже если передавать не мок, а сам объект, подключенный ко внешнему миру, то изменение его сигнатуры точно так же ломают тест. Мок только реализует ту же самую сигнатуру.
Нет теста нет проблем. Но есть другой тест - на поведение API, которому фиолетово, как мы там меняем сигнатуры в репо. Он продолжает работать, значит система в порядке.
а значит тесты кроме, возможно, приёмочных (acceptance) не нужны.
очень правильная мысль, только надо добавить, что еще нужно немного unit тестов, чтобы првоерить реакцию на ошибки, которые просто так воспроизвести тяжело.
Но цель тестов, даже приёмочных — именно в том, чтобы ломаться при изменениях (если они что-то проверяют)
Ломаться при изменениях видимого поведения системы. Это совсем не то же самое, что ломаться при любом серьезном изменению любого интерфейса.
Вопрос в эффективности и в борьбе со сложностью.
Вот смотрите, я беру код вашего repo.FindUserById и перемещаю его в статическую функцию. Затем я выкидываю сам репо за ненадобностью и все тесты с ним связанные. Так как и у вас и у меня есть тесты самого API, покрытие после этого осталось таким же. Я выкинул кучу кода и... усложнил систему и навел беспорядок? Какое такое определение сложности и порядка нужно принять, чтобы это оказалось истинным?
Мне кажется вам стоит представить более весомый пример, чтобы показать как можно "Тестировать-то можно и без тотального мокирования." Игрушечный пример, в котором 1 класс тестируется и нет IO ничего не говорит о реальной жизни. В реальной жизни у нас куча классов делает IO, и большинство остальных на них завязаны.
Ваш донат это 1001ая причина на вас наехать. Если наезд со стороны органов случится, то не потому, что вы донатили, а потому, что вы оказались в ненужном месте в ненужное время. А причина, по которой вас посадят может быть произвольной. Донат, неправильная расцветка одежды (привет Беларусь), оскорбление сотрудника мыслью, причинение испуга бумажным стаканчиком, участие в выдуманной майором организации, педофилия и так далее.
Если вы настолько обеспокоены безопасностью, то не смотрите youtube (продвижение экстремистской организации путём влияния на алгоритмы YouTube с помощью просмотра), не читайте посты где есть слова УГ, Навальный и т.п., не пишите ничего онлайн, станьте членом Единой России.
Вы, кажется, не прочитали мой комментарий и отвечаете на что-то придуманной вами. Я повторюсь
Про то, что пентест это плохо или хорошо я ничего не писал. А вот о том, что раскрытие уязвимостей без какой-либо внятной попытки связаться, это да, об этом я писал.
Вы полагаете, что оригинальный комментарий предполагал потворство дырам в безопасности? Ну ОК. Кажется тут даже ребенку понятно, что дыры это плохо, а комментатор говорит о том, что действительно важно.
Этот пост очевидная атака на проект Навального и Волкова лично. У кого-то есть нездоровое желание публиковать проблемы сайта, ну пожалуйста. Форма подачи и попытка завуалировать все это под "помощь" выглядят максимально отвратительно. Я бы автору порекомендовал переключиться на kremlin.ru.
Как-то не похоже... Хватило ума и таланта найти дыру, но написать в твиттер Волкову что-то вроде "У вас дыра, я покажу, пишите в личку" нет?
Вот вам предложение - поковыряйте сайты типа kremlin.ru, ФСБ и т.п., а затем напишите тут о дырах. После этого посмотрим насколько круто изменится ваша жизнь. Если платформа Волкова имеет под собой основания, то мы о вас тут какое-то время не услышим. Я лично буду рад, если на хабре таких желчных постов будет меньше.
Именно так, если вы используете нормальный фреймворк, то все это у вас уже есть, осталось включить в конфиге. Скорее всего не будет защиты от DDoS, но тут вам помогут облака и/или cloudflare. Если же у вас нет фреймворка и вы все написани на чистом C, то вам поможет AWS API GW. Хотя тут, конечно, вопросы будут к SQL injection и аналогам, то есть ошибкам и небрежностям в кодировании.
Мне не очень понятно что означает "закладывать защиту на уровне дизайна". Защита это аспект, которые все известные мне среды разработки стараются максимально отделить от бизнес логики. Потому и включается все это в конфиге или подключением модулей/библиотек.
И не найдут, потому что не надо все переделывать. Непонятно как вообще надо сделать систему, чтобы в неё нельзя было добавить авторизацию. В каждом фреймворке это есть, что надо было сделать, чтобы нельзя было просто включить встроенную функцию?
>Или это всё-таки фреймворки/технологии, а именно решение мне надо будет писать самому?
Процитирую самого себя
>Обработка событий, которые возникают в рамках интеграции может быть произвольно сложной, но это и есть бизнес логика, которую никто за вас не напишет.
Да, вам нужно собрать решение и часто нужно для этого писать код.
Тогда возникает сомнение, что это типовое решение... Ну в самом деле, типовое решение, которое не решает типовые проблемы, это очень странно.
Вот тут совсем непонятно. Как может типовое решение быть хуже самопала для типичного использования? Понятно, что оно дешевле, потому что продается на потоке. Но оно еще может быть и лучше, потому что в него денег вливается предположительно сильно больше, чем покупатель может себе позволить.
AWS SNS/Lambda/Step Functions + C# не поможет? Возможно есть что-то более специализированное и тогда следует взять это решение, при прочих равных.
Если заказчик сидел на типовом решении, то можно предположить, что интеграции с компаниями типа Nagel-Group для пользователей этого решения не редкость. Не обязательно конкретно Nagel-Group, не обязательно именно такая интеграция какую вы в итоге сделали. Но следует ожидать, что у пользователей коробки проблемы примерно одинаковые и решения тоже. Тогда должно получаться, что как только пользователь коробки дорос до Nagel-Group, то все, баста, приехали. Опытный интегратор об этих ограничениях должен знать, а неопытный провести достаточно исследований чтобы распознать.
Я думаю, что на самом деле происходит не так. А сначала интегратор, который плохо понимает платформу и учится по ходу, лепит решение, а затем оказывается, что оно плохое. Либо типовое решение изначально было выбрано неверное. Либо компания переросла это решение, как Washington Post перерос WordPress. В любом случае, кроме первого, все нормально, типовые решения не обязаны быть абсолютно универсальными.
А вот первый случай это пример непрофессионализма и защищать его не стоит. Также непрофессионально (и вредно для доходов) впаривать кастомное решение заказчику, который явно требует типовое решение. Я полагаю, что проблема автора статьи в том, что имея в руках Java/C#/PHP все кажется кастомной программой. Не имея опыта в конкретной области заказчика ему впихивают ненужное решение, а он сопротивляется. И все это выдается как поучительная история о том, какие заказчики дебилы.
Возвращаясь к дихотомии Washington Post - WordPress мне хочется вам задать вопрос. WordPress не подходит крупной газете (как минимум) из-за размеров организации, штата редакторов, продажи рекламы и всяких процессов которые с этим связаны и требуют автоматизации. В WordPress я могу указать на массу функций, которых в нем просто нет и обосновать, что добавлять все это в него сложнее, чем писать систему с нуля. А в чем был фатальный недостаток того типового решения, которое вы заменяли?
Не думаю, что есть такие заказчики, которые хотят самое дешевое решение несмотря ни на что. Заказчик обычно ищет оптимальное соотношение цена-качество. Моя проблема со всеми фреймворками ровно в том, что заказчика чаще всего вводят в заблуждение касательно реальной стоимости разработки, а главное поддержки этого агрегата. Если бы заказчику сразу сказали, тебе теперь нужна команда из 3х человек и ФОТ для них в 12 млн в год, то он бы очень сильно подумал о нетиповых хотелках.
Если получив задачу интеграции с Rewe/Aldi/Metro или Nagel-Group вы 2 месяца тратите на фреймворк для интеграций, то вы точно что-то делаете не так. Обработка событий, которые возникают в рамках интеграции может быть произвольно сложной, но это и есть бизнес логика, которую никто за вас не напишет. Штуки вроде доставки сообщений, их хранение, повтор в случае ошибки, всякие панели управления и мониторинги, оркестрация разных сервисов, все это давно решено. То есть получив задачу на интеграцию будет правильно просто сделать интеграцию, а не разрабатывать фреймворк для описания интеграций.
Вот смотрите
Выглядит как типовая задача - бизнес процесс надо организовать, есть миллион решений, но сразу же речь идет о "платформе". Задача о взаимодействии разных ролей стара как персональный компьютер. Игнорировать последние 30 лет развития и писать свою платформу для этого глупо. Заказчик не дурак, он то понимает, что что-то идет не так и сопротивляется.
С языка сняли. Заказчик точно хочет типовое решение, а ему продают уникальный предмет искусства ручной работы. Причём это похоже на бизнес заказчика, область, в которой уже давно сделали все возможные фреймворки, но ему продают очередной такой фреймворк, видимо чтобы он побольше страдал в будущем.
Я не понимаю зачем вы придумываете высказывания, приписываете их мне и комментируете… но мне точно не интересно в эти игры играть. Мне интересно другое - я пытаюсь вашу позицию понять. Про электриков я все понял, а также про то, что разные бывают виды оплаты труда. Но я тут говорю о вполне конкретной ситуации, она на практике постоянно встречается - задачи в беклоге не кончаются. И мне интересно, как вы в такой ситуации будете работать. Если ответ - 4 часа потому что платят 5 копеек, то пусть так и будет. Просто хочется ясности.
Мнение понятно отчего при разговоре о DDD всплывает постоянно Event Sourcing? Когда речь заходит про event sourcing нужно всегда уточнять, что правильно его реализовать очень сложно и дорого. Потому что все должно быть 100% детерминированно.
У вас где-то concurrent ordered map, скорее всего там skip list и рандом внутри. А значит порядок обхода этой коллекции будет разным при каждом запуске.
DateTime.Now, очевидно.
Настройки системы, например дефолтный часовой пояс.
Настройки самой программы. Типа размер кеша.
Можно поискать в блоге LMAX рассказы о том, как они решают эти проблемы. Это долго, дорого и больно. Не надо event sourcing если у вас не high load и не сложная in-memory модель (обычно это из-за требований к latency) короче если вы не делаете биржу или мультиплеер в реальном времени это не ваше.
Озвучил - "прилагать максимально возможный уровень усилий, который позволит продолжать деятельность, без падения продуктивности, до выхода на пенсию." Добавлю - это и есть определение "продуктивного времени", с которого все началось.
И мне не понятно с чем тут можно не согласится?
А в чем профит от того, что тесты и код пишут разные люди?
Звучит интересно, я теоретизировал на эту тему, но до практики не дошло. Расскажите больше. Тесты пишет архитектор, а заставляют их работать программисты? Тесты на все или только на АПИ? Как изолируется окружение типа БД и прочие зависимости, которые сложно замокать?
Как он может не работать, если есть прямая инструкция брать следующую задачу из беклога? Если он так делает, то нарушает договоренности и это как раз и есть тот обман, с которого все началось.
Конечно, я же так похож на карикатурного буржуя-эксплуататора из советских агиток.
Разные работодатели платят за разные вещи, а скорость света в вакууме есть константа, какие ещё очевидные факты нам нужно прояснить? На самом деле мне просто интересно, что вы будете делать если получите прямую инструкцию работать 8 часов в день, выбирая задачи из бесконечного беклога. Будете ли вы осознанно саботировать процесс, мотивируя это тем, что платят мало или, что Вася в 2 раза медленнее работает, а получает столько же. Или просто будете работать?
В качестве примера силы TDD вы привели приложение, которое было создано в 2016 году, а первый тест у него появился в 2018. Вот это test first!
О!!!! так вы же и автор, и после этого вы мне за TDD втираете?
Ну все, вы меня свалили своими аргументами, валяюсь под столом. Я уверовал, что TDD без моков возможно - это когда сначала код, а затем тесты, и тесты гоняют реальное приложение со всей инфраструктурой. Если кто-то назовет это функциональным, интеграционным или acceptance тестом, то мы его вместе выследим и заставим извиниться на камеру за такую ересь. Спасибо, что открыли глаза.
Удобно, я вам даю набор предикатов и чтобы все расставить по местам достаточно показать, что один из них неверен, не стоит ради этого такие сочинения писать.
Вы сравниваете
public User FindById()сpublic static User FindById(this DbContext db). Какая тут разница в локализации функционала?Нет теста нет проблем. Но есть другой тест - на поведение API, которому фиолетово, как мы там меняем сигнатуры в репо. Он продолжает работать, значит система в порядке.
очень правильная мысль, только надо добавить, что еще нужно немного unit тестов, чтобы првоерить реакцию на ошибки, которые просто так воспроизвести тяжело.
Ломаться при изменениях видимого поведения системы. Это совсем не то же самое, что ломаться при любом серьезном изменению любого интерфейса.
Вот смотрите, я беру код вашего repo.FindUserById и перемещаю его в статическую функцию. Затем я выкидываю сам репо за ненадобностью и все тесты с ним связанные. Так как и у вас и у меня есть тесты самого API, покрытие после этого осталось таким же. Я выкинул кучу кода и... усложнил систему и навел беспорядок? Какое такое определение сложности и порядка нужно принять, чтобы это оказалось истинным?
Мне кажется вам стоит представить более весомый пример, чтобы показать как можно "Тестировать-то можно и без тотального мокирования." Игрушечный пример, в котором 1 класс тестируется и нет IO ничего не говорит о реальной жизни. В реальной жизни у нас куча классов делает IO, и большинство остальных на них завязаны.