Сокращение пяти типов до одного Mock — тоже популярный способ.
Он хорошо сочетается с модульными тестами и каноничным TDD, изложенным кратко в статье Canon TDD Кента Бека или подробно в его же книге «Экстремальное программирование: разработка через тестирование».
Аналогичный подход изложен в книге «Growing Object-Oriented Software, Guided by Tests». Само название этой книги очень правильно описывает суть подхода:
проектировать и реализовывать программу как множество объектов средствами ООП
каждый добавляемый объект покрывать тестами по циклу каноничного TDD
А есть иной подход: фокус на интеграционные приёмочные тесты. Этот подход хорошо описывают два источника:
Лично я сторонник именно второго подхода, в моей практике он прекрасно показал себя в разработке бэкенд-сервисов для бэкофисной автоматизации (то, что Джоэль Спольски в статье «Пять миров» называл миром корпоративного ПО).
Если же, например, разработчик создаёт библиотеки или фреймворки, то он может сфокусироваться на модульных тестах и использовать их как приёмочные.
От этого зависит набор используемых тестовых дублёров:
при фокусе на интеграционные приёмочные тесты и BDD / ATDD лучше всего работают Fake-объекты, на втором месте Mock
при фокусе на модульные тесты и каноничный TDD лучше всего, пожалуй, работают Mock-объекты
Впрочем, Кент Бек (создатель TDD) избегает Mock-объектов, вот цитата из статьи A week with Kent Beck:
Kent Beck explained that he does not use mocks, but instead works from the lowest assumption, validates that assumption, and works to the next. He splits up the design strategy path, and avoids to mocks by this completely.
Эта статья задумана как справочник, и я буду ссылаться на неё в следующих статьях. Следом будет статья про внешние API в интеграционных тестах API-сервисов, и там я покажу применение 4 из 5 типов: Fake, Mock, Spy, Stub.
В реальной практике можно сократить инструментарий до 4, 3, 2 или даже единственного типа дублёра. Но возникает вопрос: какие именно типы выбросить?
С подачи Мартина Фаулера и Владимира Хорикова популярна дихотомия Mock vs Stub. И я считаю это ошибкой. В моей личной практике (с фокусом на интеграционные приёмочные тесты) чаще всего я выбирал Fake. На второе место я бы поставил Spy/Mock (я их не различал до недавних пор).
Итого: если дихотомия, то лучше оставить Fake и Mock, а не Stub и Mock. Игнорирование Fake или неумение их писать снижает качество тестов в целом.
В пирамиду тестирования не верю, видимо пишу слишком простые простые и получается, что интеграционных тестов сильно больше, чем юнитов.
Kent Dodds, автор Testing Library (ранее известной как React Testing Library), также предпочитает в основном интеграционные тесты: Write tests. Not too many. Mostly integration. Он придумал концепцию Testing Trophy в качестве метафоры для такого подхода.
Также упор на интеграционные тесты иногда называют Testing Diamond (термин более ранний, но я не смог отследить его первоисточник).
А если уходить вглубь истории, есть такой интересный нюанс с появлением термина Пирамида Тестирования:
в 2009 году Mike Cohn написал статью The Forgotten Layer of the Test Automation Pyramid, суть которой можно описать так: разработчики пишут unit-тесты, QA пишут сквозные тесты, все забывают про интеграционные тесты (в статье названы Service Tests)
в той же статье он в качестве метафоры показал Пирамиду Тестирования (Testing Automation Pyramid)
затем в 2010 году в книге "Succeeding with Agile: Software Development Using Scrum" он ещё раз представил метафору Пирамиды Тестирования
Так вот: пирамида тестирования у Mike Cohn была лишь иллюстрацией к статье, а соль статьи именно в рекомендации обратить внимание на интеграционные тесты. Но почему-то в индустрии запомнили термин Пирамида Тестирования, а про интеграционные тесты снова забыли.
Запилили разработчики госуслуг, а заслуга почему-то правозащитников. Интересно, а если правозащитник на stackoverflow за ответ проголосует и потом автор этот ответ примет как лучший, тоже будет новость и дифирамбы в честь правозащитников на хабре?
Это же skillfactory, они не шибко ценят глубину, качество или уровень конверсии в специалистов и работают на количество и конверсию денежную. Похоже на зарубежные кемпинги, где за 3 месяца человека учат кое-как программировать и хорошо скрывать это на собеседованиях.
Насчёт ACID транзакций вы правы, я ошибся на этот счёт. Хотя, конечно, поведение транзакций несколько отличается от SQL и не позволяет получить данные, принять решение, записать данные - такое, насколько мне известно, достижимо только через Redis Script.
Что касается "как и SQL": да, настройками Redis можно достичь тех же гарантий, что у MySQL, но это полностью уберёт преимущества в производительности, при этом Redis останется однопоточным, а MySQL - многопоточным.
Ну и кроме того, если мы превращаем Redis в однопоточный и ограниченный по функциональности аналог MySQL, то в чём смысл такой инсталяции Redis?
Если же не превращаем, то сказанное в статье верно.
И в любом случае, Redis в дополнение к основной БД - это новая точка отказа. Посыл статьи вовсе не в том, что Redis не надо использовать. Посыл в том, что использование должно быть оправдано, а реализация должна быть адекватной, если проекту важна отказоустойчивость.
Я не вижу противоречия разных формулировок, потому что разные формулировки говорят о разных уровнях.
В книге Clean Architecture речь идёт о крупномасштабной структуре программы, и на таком уровне модуль действительно может закрывать потребности одного actor (действующего лица):
A module should be responsible to one, and only one, actor
Если же речь идёт о внутренней структуре модуля, то здесь работает разделение по аспектам реализации. И, кстати, в формулировке 2014 года Роберт Мартин уже убрал единственное число и говорит об изменениях по схожим причинам:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
В такой формулировке выделение слоя для работы с SQL полностью соответствует SRP: у кода для работы с БД действительно все причины изменений схожи.
Ну и наконец, Роберт Мартин прямо пишет в Clean Architecture, что принцип SRP надо соблюдать примерно на 90%.
Так что не надо обесценивать SRP, и тем более не надо заменять его на "практические рекомендации", весьма спорные и выходящие из моды за несколько лет.
Может я чего-то не учитываю, но я не понимаю, зачем нужен blue/green, когда есть rolling update и staging окружение, близкое к production.
С канареечным понятно — позволяет подвергнуть риску регрессий лишь часть пользователей, и, если скорость реакции на инциденты у разработчиков высокая, а период до полного выката достаточен, то снизит риски.
А что такого несёт blue/green — не понимаю. Разве что как костыль для сокращения периода одновременной работы двух версий (то есть как "антиканареечный" деплой)
Ходили слухи о проблемах в октябре сразу у многих облачных провайдеров — netrack, croc, selectel и других.
Но при этом у Amazon всё стабильно в порядке, с начала пандемии.
Всё-таки дело не только и не столько в переводе инженеров на удалёнку.
P.S. Нагрузка на сеть везде есть, весной были проблемы с каналом из России в Европу, сейчас есть проблемы со скоростью серверов в США из арабских стран. Но справляются все по-разному.
Почему решили с MySQL переходить на PostgreSQL? Были ли трудности при внедрении в новых сервисах PostgreSQL?
Запись в микросервис, абстрагирующий Kafka, выполняется напрямую или через базу и Transactional Outbox?
Базы данных и Kafka развёрнуты вне Kubernetes? Есть ли ситуации, когда одна машина с инстансами БД или один инстанс БД с разными database используется несколькими микросервисами?
Если будет запрет на использование американских технологий, то из AppStore и GooglePlay уберут насовсем, не только на территории США.
Huawei, например, использовать приложения гугла не может нигде.
"Яндекс сливал данные" — это такое народное поверье, или есть доказательства?
Уточню, что речь не о выдаче данных в пределах юрисдикции страны — таким-то и Google регулярно занимается, причём во всех странах и в США прежде всего.
Но секундочку, речь вообще-то о том, что VK встал в защиту (в данном случае украинских) пользователей от российских судебных решений в 2014 году, и ваш комментарий лишь больше подтверждает мои слова — потому что реакцией VK на уголовные дела по репостам стало скрытие списка репостов.
Речь о тех, кто вводил запреты и нагнетал истерию — в основном про период между Януковичем и Зеленским, конечно.
Правда, внедрённые в тот период запреты и сейчас никуда не делись, так что власть не то что бы прямо сильно сменилась. Запрет на ряд российских сервисов продлили недавно, да и с незапрещёнными украинский бизнес не особо желает теперь связываться, именно из-за политики запретов и поддержки её со стороны СБУ.
С чего вдруг такое будет в московских офисах?
Давайте, кстати, вспомним, что первыми на Яндекс набросились украинские власти — заблокировали счета, так что даже зарплаты нельзя было выплатить. Исполнили давнюю мечту националистов — "вiдсечь" всё русское.
Удивляет, что на хабре сравнивают события в Беларусь с Россией, учитывая, что по нетерпимости к оппонентам Лукашенко больше похож на новые украинские власти, которые запретили КПУ, запретили российские телеканалы, запретили популярные российские сервисы (несмотря на то, что тот же VK прямо отказался выдавать что-либо ФСБ или блокировать группы по решению российского суда).
Не сравнивайте, пожалуйста, с современной Россией, уймите свои фобии. У нас что-то подобное было лишь в 1993м году.
На github в поиске по запросу golang scratch docker в топе сразу два примера, где данные о timezone добавляются в контейнер.
А все статьи по этой теме, к сожалению, поверхностные: я не видел упоминаний timezone, не всегда предлагается менять пользователя с root на ограниченного, в этой статье (не в вину переводчику, конечно) ещё и про multi-stage builds не сказано ничего.
Сокращение пяти типов до одного Mock — тоже популярный способ.
Он хорошо сочетается с модульными тестами и каноничным TDD, изложенным кратко в статье Canon TDD Кента Бека или подробно в его же книге «Экстремальное программирование: разработка через тестирование».
Аналогичный подход изложен в книге «Growing Object-Oriented Software, Guided by Tests». Само название этой книги очень правильно описывает суть подхода:
проектировать и реализовывать программу как множество объектов средствами ООП
каждый добавляемый объект покрывать тестами по циклу каноничного TDD
А есть иной подход: фокус на интеграционные приёмочные тесты. Этот подход хорошо описывают два источника:
статья Владимира Хорикова Отзыв на книгу Growing Object-Oriented Software, Guided by Tests
статьи Кента Доддса, автора React Testing Library (ныне просто Testing Library): Write tests. Not too many. Mostly integration.
Лично я сторонник именно второго подхода, в моей практике он прекрасно показал себя в разработке бэкенд-сервисов для бэкофисной автоматизации (то, что Джоэль Спольски в статье «Пять миров» называл миром корпоративного ПО).
Если же, например, разработчик создаёт библиотеки или фреймворки, то он может сфокусироваться на модульных тестах и использовать их как приёмочные.
От этого зависит набор используемых тестовых дублёров:
при фокусе на интеграционные приёмочные тесты и BDD / ATDD лучше всего работают Fake-объекты, на втором месте Mock
при фокусе на модульные тесты и каноничный TDD лучше всего, пожалуй, работают Mock-объекты
Впрочем, Кент Бек (создатель TDD) избегает Mock-объектов, вот цитата из статьи A week with Kent Beck:
Эта статья задумана как справочник, и я буду ссылаться на неё в следующих статьях.
Следом будет статья про внешние API в интеграционных тестах API-сервисов, и там я покажу применение 4 из 5 типов: Fake, Mock, Spy, Stub.
В реальной практике можно сократить инструментарий до 4, 3, 2 или даже единственного типа дублёра. Но возникает вопрос: какие именно типы выбросить?
С подачи Мартина Фаулера и Владимира Хорикова популярна дихотомия Mock vs Stub. И я считаю это ошибкой. В моей личной практике (с фокусом на интеграционные приёмочные тесты) чаще всего я выбирал Fake. На второе место я бы поставил Spy/Mock (я их не различал до недавних пор).
Итого: если дихотомия, то лучше оставить Fake и Mock, а не Stub и Mock. Игнорирование Fake или неумение их писать снижает качество тестов в целом.
Какая именно in-memory БД используется, если не секрет?
та же СУБД, как на проде (будь то PostgreSQL, MS SQL, MySQL)
или SQLite в режиме in-memory
или
Microsoft.EntityFrameworkCore.InMemoryили что-то иное
И речь о C# / .NET или о другой платформе?
Kent Dodds, автор Testing Library (ранее известной как React Testing Library), также предпочитает в основном интеграционные тесты: Write tests. Not too many. Mostly integration. Он придумал концепцию Testing Trophy в качестве метафоры для такого подхода.
Также упор на интеграционные тесты иногда называют Testing Diamond (термин более ранний, но я не смог отследить его первоисточник).
А если уходить вглубь истории, есть такой интересный нюанс с появлением термина Пирамида Тестирования:
в 2009 году Mike Cohn написал статью The Forgotten Layer of the Test Automation Pyramid, суть которой можно описать так: разработчики пишут unit-тесты, QA пишут сквозные тесты, все забывают про интеграционные тесты (в статье названы Service Tests)
в той же статье он в качестве метафоры показал Пирамиду Тестирования (Testing Automation Pyramid)
затем в 2010 году в книге "Succeeding with Agile: Software Development Using Scrum" он ещё раз представил метафору Пирамиды Тестирования
Так вот: пирамида тестирования у Mike Cohn была лишь иллюстрацией к статье, а соль статьи именно в рекомендации обратить внимание на интеграционные тесты. Но почему-то в индустрии запомнили термин Пирамида Тестирования, а про интеграционные тесты снова забыли.
Запилили разработчики госуслуг, а заслуга почему-то правозащитников. Интересно, а если правозащитник на stackoverflow за ответ проголосует и потом автор этот ответ примет как лучший, тоже будет новость и дифирамбы в честь правозащитников на хабре?
Это же skillfactory, они не шибко ценят глубину, качество или уровень конверсии в специалистов и работают на количество и конверсию денежную. Похоже на зарубежные кемпинги, где за 3 месяца человека учат кое-как программировать и хорошо скрывать это на собеседованиях.
Насчёт ACID транзакций вы правы, я ошибся на этот счёт. Хотя, конечно, поведение транзакций несколько отличается от SQL и не позволяет получить данные, принять решение, записать данные - такое, насколько мне известно, достижимо только через Redis Script.
Что касается "как и SQL": да, настройками Redis можно достичь тех же гарантий, что у MySQL, но это полностью уберёт преимущества в производительности, при этом Redis останется однопоточным, а MySQL - многопоточным.
Ну и кроме того, если мы превращаем Redis в однопоточный и ограниченный по функциональности аналог MySQL, то в чём смысл такой инсталяции Redis?
Если же не превращаем, то сказанное в статье верно.
И в любом случае, Redis в дополнение к основной БД - это новая точка отказа. Посыл статьи вовсе не в том, что Redis не надо использовать. Посыл в том, что использование должно быть оправдано, а реализация должна быть адекватной, если проекту важна отказоустойчивость.
Анекдот неприличный, вряд ли я могу цитировать его на хабре. Предлагаю в яндексе набрать "мужик сено скафандр" :)
И, кстати, actor и stakeholder - разные вещи, почему автор решил, что можно одно заменить на другое, не будучи при этом носителем английского языка?
Разница объясняется, например, здесь: http://fserranocs460.blogspot.com/2014/01/use-cases-actors-vs-stakeholders.html
Я не вижу противоречия разных формулировок, потому что разные формулировки говорят о разных уровнях.
В книге Clean Architecture речь идёт о крупномасштабной структуре программы, и на таком уровне модуль действительно может закрывать потребности одного actor (действующего лица):
Если же речь идёт о внутренней структуре модуля, то здесь работает разделение по аспектам реализации. И, кстати, в формулировке 2014 года Роберт Мартин уже убрал единственное число и говорит об изменениях по схожим причинам:
В такой формулировке выделение слоя для работы с SQL полностью соответствует SRP: у кода для работы с БД действительно все причины изменений схожи.
Ну и наконец, Роберт Мартин прямо пишет в Clean Architecture, что принцип SRP надо соблюдать примерно на 90%.
Так что не надо обесценивать SRP, и тем более не надо заменять его на "практические рекомендации", весьма спорные и выходящие из моды за несколько лет.
Может я чего-то не учитываю, но я не понимаю, зачем нужен blue/green, когда есть rolling update и staging окружение, близкое к production.
С канареечным понятно — позволяет подвергнуть риску регрессий лишь часть пользователей, и, если скорость реакции на инциденты у разработчиков высокая, а период до полного выката достаточен, то снизит риски.
А что такого несёт blue/green — не понимаю. Разве что как костыль для сокращения периода одновременной работы двух версий (то есть как "антиканареечный" деплой)
Ходили слухи о проблемах в октябре сразу у многих облачных провайдеров — netrack, croc, selectel и других.
Но при этом у Amazon всё стабильно в порядке, с начала пандемии.
Всё-таки дело не только и не столько в переводе инженеров на удалёнку.
P.S. Нагрузка на сеть везде есть, весной были проблемы с каналом из России в Европу, сейчас есть проблемы со скоростью серверов в США из арабских стран. Но справляются все по-разному.
Спасибо за статью, хотелось бы ещё узнать
Если будет запрет на использование американских технологий, то из AppStore и GooglePlay уберут насовсем, не только на территории США.
Huawei, например, использовать приложения гугла не может нигде.
Как мне кажется, договариваться будут, но сильно позже и уже без участия США. Там, где штаты имеют влияние, Китай едва ли пустят — как уже было с МКС.
"Яндекс сливал данные" — это такое народное поверье, или есть доказательства?
Уточню, что речь не о выдаче данных в пределах юрисдикции страны — таким-то и Google регулярно занимается, причём во всех странах и в США прежде всего.
Но секундочку, речь вообще-то о том, что VK встал в защиту (в данном случае украинских) пользователей от российских судебных решений в 2014 году, и ваш комментарий лишь больше подтверждает мои слова — потому что реакцией VK на уголовные дела по репостам стало скрытие списка репостов.
Речь о тех, кто вводил запреты и нагнетал истерию — в основном про период между Януковичем и Зеленским, конечно.
Правда, внедрённые в тот период запреты и сейчас никуда не делись, так что власть не то что бы прямо сильно сменилась. Запрет на ряд российских сервисов продлили недавно, да и с незапрещёнными украинский бизнес не особо желает теперь связываться, именно из-за политики запретов и поддержки её со стороны СБУ.
С чего вдруг такое будет в московских офисах?
Давайте, кстати, вспомним, что первыми на Яндекс набросились украинские власти — заблокировали счета, так что даже зарплаты нельзя было выплатить. Исполнили давнюю мечту националистов — "вiдсечь" всё русское.
Удивляет, что на хабре сравнивают события в Беларусь с Россией, учитывая, что по нетерпимости к оппонентам Лукашенко больше похож на новые украинские власти, которые запретили КПУ, запретили российские телеканалы, запретили популярные российские сервисы (несмотря на то, что тот же VK прямо отказался выдавать что-либо ФСБ или блокировать группы по решению российского суда).
Не сравнивайте, пожалуйста, с современной Россией, уймите свои фобии. У нас что-то подобное было лишь в 1993м году.
На github в поиске по запросу golang scratch docker в топе сразу два примера, где данные о timezone добавляются в контейнер.
А все статьи по этой теме, к сожалению, поверхностные: я не видел упоминаний timezone, не всегда предлагается менять пользователя с root на ограниченного, в этой статье (не в вину переводчику, конечно) ещё и про multi-stage builds не сказано ничего.