Почему-то вспомнился чемпионат Russian AI Cup далекого 2015-го, где надо было по трассе гонять машинки. На Хабре есть увлекательный пост от победителя того турнира о том, как он решал задачу: habr.com/ru/post/273649. Конечно, тогда задача была куда сложнее, чем описана в данной статье. Тем не менее, что интересно, на упомянутых соревнованиях никто из победителей не использует нейросети, хотя генетические алгоритмы в «историях успеха» упоминались.
При редактировании потерялось «не», прошу прощения. Я имел в виду «тривиальные моки пишутся все же не на тест, но на сюиту». А так я и писал, что чем больше модулей и связей охватывает тест, чем выше в иерархии он находится, тем сложнее моки. У юнита самые простые, у модуля сложнее и так далее.
Возможно, мы по-разному понимаем термины «модуль» и «компонент», это может зависеть от языка, и менеджера пакетов или используемого фреймворка.
В случае юниов такие же тривиальные моки пишутся все же на тест, но на сюиту. Но часто поведение сервиса более сложное, чем поведение маленького компонента. Соответственно и моки становятся все сложнее и сложнее.
Это означает, что ваши зависимости становятся сложными, функции перестают быть чистыми, и начинают что-то подозревать о своих зависимостях. Ваш конкретный пример, если я правильно понимаю, уже содержит слой моков, контекст. Это далеко не всегда возможно обеспечить. В моем проекте моки для юнит тестов намного проще, чем моки для интеграционных.
Ни в одной из своих OSS библиотек я не сломал обратную совместимость с версией v0.1.0. Среди них есть и довольно замысловатые.
Либо вы гениальный дизайнер интерфейсов, либо вам повезло и последующие версии были просто расширением первоначальной, либо вы теперь поддержваете кучу легаси. Одно из трех.
Я бы пришиб любого, кто пришел бы ко мне с приветом «а теперь поменяй все свои вызовы нашего микросервиса, потому что мы переписали API».
Это вы своих коллег не любите :-) Кроме внешних интерфейсов с версионированием и обратной совместимостью бывают еще внутренние API сервисов, которые активно живут и меняются, вот интерфейсы классов, например. Они просто обязаны меняться, иначе проект либо обрастает адапторами-костылями, либо дизайн становится неуправляемым спагетти с подпорками.
API — Это в том числе и интерфейсы внутренних компонентов сервиса, которые не публичны, могут менятся, и вполне себе тестируются интеграционным тестированием.
в них не существует способа протестировать приватную функцию
FYI: в некоторых из них нет и приватных функций вообще. Но как только ваш приватный код становится достаточно сложным, его приходится вытаскивать в видимую область (пространства имен details, например) и даже делать библиотечным, и покрывать тестами, чтобы избежать катастрофы от безобидного изменения.
Культура разработки — это не менять API, не ломать обратную совместимость — и не тестировать детали реализации
Если у вас относительно молодой проект, то вы будете делать все три перечисленные вещи.
Когда я поломал интеграционный тест — то это, в 90% случаев ошибка, которую нужно править. Если я поломал end-to-end — это это уже в 99% случаев ошибка, без исправления которой релиза не будет.
Кто-то поменял API, кто-то поменял внутренее поведение — и куча ваших интеграционных тестов требуют адаптации, все точно так же как и юнит тесты. На самом деле я ни разу не написал, что остальные тесты не нужны. Очень нужны и очень важны! Но чем ниже в иерархии находится тест, тем проще его писать. А правильный дизайн позволяет писать тесты на более низком уровне.
В результате в тех 10% случаев, когда они таки срабатывают «по делу» — они, зачастую, точно так же механически «затыкаются» и свою функцию не исполняют.
Это культура разработки в команде. В моем случае срабатывание юнит-теста как правило означает проблему в коде. И при рефакторинге юниты позволяют сильно упростить верификацию изменений. При разработке нового функционала низкого уровня они позволяют описать требования.
Тем не менее, чтобы получить «kernel oops» — вам нужно постараться, а завалить какую-нибудь эту «суперпротестированноу» бизнесс-програму часто можно парой кликов мышкой в неподходящий момент.
Я бы тоже не стал сравнивать код написанный лучшими умами мира и отлаженный миллионами юзеров, с говнокодом, покрытым каргокультовыми тестами, которые на самом деле ничего не проверяют.
Дочитал до этой цитаты про первый-второй пример кода:
Хотя некоторым подобные изменения могут показаться усовершенствованиями, важно указать на то, что определённые нами интерфейсы не имеют практической пользы, за исключением возможности проведения юнит-тестирования.
Нет, это не измения ради юнит-тестирования, это применение принципов инверсии зависимости и единой ответственности из SOLID. Хорошая практика проектирования, которая в перспективе экономит очень много времени и нервов при последующем изменении кода. И да, она же внезапно позволяет коду быть легко тестируемым, а значит более надежным. И сильно упрощает написание тестовых моков.
Я лично считаю, что юнит тесты — это самые простые для написания тесты, потому что для них нужно минимум инфраструктуры, и пишут их те же программисты, которые пишут код. По факту, это единственные тесты, которые могут тестировать внутренности реализации. Когда дело доходит до интеграционных тестов, оказывается, что заглушки для целых компонентов писать много сложнее. А c end-to-end тестами вообще часто беда, они выполняются долго, требуют сложной инфраструктуры и отдельных тестеров-автоматизаторов для поддержки.
Если мы прячем население на очень жесткий карантин, мы все равно можем получить именно точку а не прямую перегиба, потому что в этом случае огромное количество людей выносятся из статистики, а функция показывает распределение на том контактировавшем количестве населения, которое случилось до карантина. Т.е. по большому счету анализируется не все население страны, а малая его часть.
Есть только пара проблем. Во-первых, китайской статистике доверять сложно, потому что никто не знает, окончилась ли там эпидемия.
Во-вторых, мне кажется, что ваша кривая работает для случая обычной эпидемии, но в случае карантина различной строгости может произойти несколько вещей. Возможно ли что точка перегиба превратится в прямую, если количество новых смертей стабилизируется на долгое время? Возможно ли, что после снятия карантинных мер эпидемия разгорится вновь, и мы получим новый взлет и перегиб?
Пока что ни в одной стране не достигнуто даже близко количество заболевших, достаточное для установление группового имуннитета. Вакцина тоже в совсем ближайшем будущем не предвидится. Это значит, что о конце эпидемии говорить пока что очень рано.
Спасибо за статью, я, наконец, сподобился добавить эту разметку в свой блог.
Судя по всему у вас в конце статьи неточность. Согласно официальной документации, для использования Open Graph тег <html> должен ипользовать не аттрибут xmlns:og=, но prefix= и должен выглядеть вот так:
<html prefix="og: http://ogp.me/ns#">
По-крайней мере, с первым вариантом аттрибута ФБ моей разметки не увидел.
Я думаю, что сторителлер сформулировал основную опасность вируса: из-за скачка больных закончились места в больницах и часть критических больных не смогли вытащить (это наглядно произошло в Италии, а Китай успел за две недели посроить несколько больниц, но и там мест было впритык). Точно так же он вполне правильно в среднем пишет про запаздывания стистики. И еще он в общем-то верно пишет, что надо делать: замедлить рост заболевших и изолировать людей если есть такая возможность.
В общем, вышел неплохой научпоп. А смотреть правильные идеально точные научные ролики на два часа… Вы меня извините, у вас прямо вот так много свободного времени?
Официальная статистика запаздывает на 10+ дней, поэтому когда количество реальных новых заражений уже идет на убыль, официальные данные все еще растут, потому что отображает людей, заразившихся неделю-две до теста, или как минимум два-три дня проявляющих симптомы.
Естественное состояние человека — это здоровый организм, всё остальное — это последствия образа жизни и отсутствия знаний об устройстве и функционировании своего аватара.
Рак, вирусы, травмы, паразиты, послеродовые осложнения как мамы так и ребенка, генетические болезни. Дальше продолжать? Здоровый образ жизни тут ни при чем.
Любая НЕорганика организму только вредит, мертвое живому не подходит.
Без солей вы умрете. Без воды вы умрете. Без воздуха вы умрете даже быстрее!
Очень хорошая статья от человека, который, судя по всему, молод, обладает хорошим здоровьем и не нуждается в медицинских услугах, ну разве что про гриппе приходится больничный оформлять.
Возможно, мы по-разному понимаем термины «модуль» и «компонент», это может зависеть от языка, и менеджера пакетов или используемого фреймворка.
Либо вы гениальный дизайнер интерфейсов, либо вам повезло и последующие версии были просто расширением первоначальной, либо вы теперь поддержваете кучу легаси. Одно из трех.
Это вы своих коллег не любите :-) Кроме внешних интерфейсов с версионированием и обратной совместимостью бывают еще внутренние API сервисов, которые активно живут и меняются, вот интерфейсы классов, например. Они просто обязаны меняться, иначе проект либо обрастает адапторами-костылями, либо дизайн становится неуправляемым спагетти с подпорками.
FYI: в некоторых из них нет и приватных функций вообще. Но как только ваш приватный код становится достаточно сложным, его приходится вытаскивать в видимую область (пространства имен details, например) и даже делать библиотечным, и покрывать тестами, чтобы избежать катастрофы от безобидного изменения.
Если у вас относительно молодой проект, то вы будете делать все три перечисленные вещи.
Кто-то поменял API, кто-то поменял внутренее поведение — и куча ваших интеграционных тестов требуют адаптации, все точно так же как и юнит тесты. На самом деле я ни разу не написал, что остальные тесты не нужны. Очень нужны и очень важны! Но чем ниже в иерархии находится тест, тем проще его писать. А правильный дизайн позволяет писать тесты на более низком уровне.
Это культура разработки в команде. В моем случае срабатывание юнит-теста как правило означает проблему в коде. И при рефакторинге юниты позволяют сильно упростить верификацию изменений. При разработке нового функционала низкого уровня они позволяют описать требования.
Я бы тоже не стал сравнивать код написанный лучшими умами мира и отлаженный миллионами юзеров, с говнокодом, покрытым каргокультовыми тестами, которые на самом деле ничего не проверяют.
Нет, это не измения ради юнит-тестирования, это применение принципов инверсии зависимости и единой ответственности из SOLID. Хорошая практика проектирования, которая в перспективе экономит очень много времени и нервов при последующем изменении кода. И да, она же внезапно позволяет коду быть легко тестируемым, а значит более надежным. И сильно упрощает написание тестовых моков.
Я лично считаю, что юнит тесты — это самые простые для написания тесты, потому что для них нужно минимум инфраструктуры, и пишут их те же программисты, которые пишут код. По факту, это единственные тесты, которые могут тестировать внутренности реализации. Когда дело доходит до интеграционных тестов, оказывается, что заглушки для целых компонентов писать много сложнее. А c end-to-end тестами вообще часто беда, они выполняются долго, требуют сложной инфраструктуры и отдельных тестеров-автоматизаторов для поддержки.
Во-вторых, мне кажется, что ваша кривая работает для случая обычной эпидемии, но в случае карантина различной строгости может произойти несколько вещей. Возможно ли что точка перегиба превратится в прямую, если количество новых смертей стабилизируется на долгое время? Возможно ли, что после снятия карантинных мер эпидемия разгорится вновь, и мы получим новый взлет и перегиб?
Пока что ни в одной стране не достигнуто даже близко количество заболевших, достаточное для установление группового имуннитета. Вакцина тоже в совсем ближайшем будущем не предвидится. Это значит, что о конце эпидемии говорить пока что очень рано.
Судя по всему у вас в конце статьи неточность. Согласно официальной документации, для использования Open Graph тег <html> должен ипользовать не аттрибут xmlns:og=, но prefix= и должен выглядеть вот так:
По-крайней мере, с первым вариантом аттрибута ФБ моей разметки не увидел.
В общем, вышел неплохой научпоп. А смотреть правильные идеально точные научные ролики на два часа… Вы меня извините, у вас прямо вот так много свободного времени?
У меня аналогично. Оглавление — ну почти хорошо, а вся аргументация сильно хромает.
А какая органика должна остаться в воде, по-вашему?
Рак, вирусы, травмы, паразиты, послеродовые осложнения как мамы так и ребенка, генетические болезни. Дальше продолжать? Здоровый образ жизни тут ни при чем.
Без солей вы умрете. Без воды вы умрете. Без воздуха вы умрете даже быстрее!