Комментарии 10
Сейчас я сломаю себе ногу, и вы сможете убедиться, какие прекрасные костыли выпускает наша компания, и как на них удобно ковылять.
А если серьёзно, то:
- не надо двум разным сервисам лазить в общую БД
- если они уже туда лазят, то не надо делать вид, что один из них этой БД "не владеет", и по этой надуманной причине не может поднять себе тестовую базу
- научитесь нормально писать тесты на Go, при правильном подходе это делать весьма удобно
- если надо мокнуть доступ к БД, то не обязательно делать это на уровне драйвера БД, можно выделить в Go приложении отдельный тонкий слой для доступа к данным, и в тестах мокать его
Разработка это всегда компромисы, между простотой и расширяемостью, или эффективностью кода и его читаемостью.
Вероятно вы имеете в виду, что правильнее было бы общаться между двумя сервисами по отдельному внутреннему API разработанному специально для этой цели. Его создание и тестирование тоже не бесплатно. А если таблицы, нужные TheService, уже годами не меняются, почему не ходить в одну базу, допустив неизменность тех таблиц?
не надо делать вид, что один из них этой БД "не владеет", и по этой надуманной причине не может поднять себе тестовую базу
"TheService" знает о существовании нескольких таблиц и использует только некоторые столбцы из них. Он не знает как создать эти таблицы, и не подозревает о существовании других столбцов и таблиц. В моем понимании это как раз "не владеет БД". Все данные о структуре таблиц в миграциях Rails. Вы что, предлагаете дублировать их в Go приложении, что бы то могло создавать себе полную тестовую базу? Поступи мы так, можно было бы писать тесты с настоящими запросами в БД прямо в Go, это один из вариантов.
Про моки не понял зачем вы советуете. У нас проблема была как раз в их наличии, т.е. тест не затрагивал базу и не гарантировал работоспособность фитчи.
Вероятно вы имеете в виду, что правильнее было бы общаться между двумя сервисами по отдельному внутреннему API разработанному специально для этой цели. Его создание и тестирование тоже не бесплатно.
Да, это один из здравых вариантов. Насчёт не бесплатно согласен, но Вы же хотите получить какие-то дополнительные плюшки от добавления микросервиса к монолиту, это никогда не бесплатно, и особенно когда это первый микросервис выделенный из монолита — он обычно тащит с собой большую часть стоимости связанной с микросервисной архитектурой, следующие добавлять будет уже дешевле.
Проблема в том, что если отказаться платить эту цену, и попытаться сэкономить используя, например, общую БД — обычно в конечном итоге это обходится заметно дороже. Конечно, из любого правила есть исключения, может конкретно Вам повезёт и всё обойдётся.
Вы что, предлагаете дублировать их в Go приложении, что бы то могло создавать себе полную тестовую базу?
Не обязательно полную, можно только ту часть, которая используется Go приложением, а можно и полную — смотря что проще. Раз уж, по Вашим же словам:
таблицы, нужные TheService, уже годами не меняются
Про моки я советовал потому, что вот это типичные признаки некорректно написанных тестов, с нормальными тестами такое происходить просто не должно:
При добавлении новой функции для чтения данных из базы, требовалось добавить для нее моки в множество упавших тестов, которые до этого работали. В результате такие юнит тесты были малоэффективными и крайне хрупкими.
Даже если поднимать не полную версию базы, Go приложение должно знать как это делать, это подразумевает дублирование информации и теоретическую возможность рассинхронизации. Например миграция в Rails затронет критическое поле, а в тестах go это изменение не внесем, тесты будут зеленые и проблема всплывет уже на QA/Production. Это маловероятно, разумеется, учитывая редкое изменения структуры базы. Но любое такое «дублирование» информации или кода не дает мне покоя.
Но любое такое «дублирование» информации или кода не дает мне покоя.
Поздно. Дублирование уже давно произошло — в тот момент, когда Вы написали на Go код, работающий напрямую с чужой БД. С этого момента у Вас уже есть и дублирование, и "теоретическая" возможность рассинхронизации.
Добавив схему для поднятия тестовой БД в микросервис Вы, всего-навсего, создадите возможность полноценно, изолировано и независимо разрабатывать, тестировать и деплоить этот микросервис, никак не вовлекая в этот процесс основной монолит. Это никоим образом не отменяет возможность (и необходимость) продолжать гонять интеграционные тесты микросервиса как описано в статье, чтобы убедиться что микросервис корректно работает с текущей БД монолита. Но интеграционные тесты и юнит-тесты это разные вещи, они дополняют друг друга, не стоит отказываться от одних в пользу других.
Идея видимо летает в воздухе. Нечто подобное тоже реализовывал https://habr.com/post/350382/
А и хорошо, что больше инструментов появляется для go! На чем бы ни были написаны.
Если ваше решение справляется с задачами, то рад за вас.
Тестирование приложения на Go как черный ящик при помощи Rspec