Modular architecture

See https://gitlab.com/picodata/picodata/picodata/-/merge_requests/52#note_851049809

Sergey V

Я вижу следующие проблемы в дизайне. Транспорт захардкожен, используется net.box, у которого нет реализации сервера на расте, и сервер можно запустить только один раз на инстанс через тарантул, и нельзя остановить без остановки процесса. На деле же в тестах реализация транспорта не тестируется. Похожая ситуация наблюдается в тестах couple и threesome: тестируется реализация raft и нашей обертки вокруг. Но из-за того, что реализация зависит от захардкоженного конкретного хранилища и транспорта, приходится затаскивать luatest, возиться с подпроцессами, временными директориями. В хорошем решении, как мне кажется, должен быть транспорт и хранилище, которые можно подменить: для транспорта реализовать простенькую структуру, чтобы в памяти одного процесса на расте имитировать пересылку messages между двумя объектами ConnectionPool, а для storage, как уже раньше говорил, сделать Storage::new(space_name_prefix, ...). И тогда можно будет тестировать всё на расте, в одном процессе, с невероятной скоростью, без лишних логов и Lua. Можно даже имитировать потерю сообщений на уровне транспорта.

added 1 deleted label

https://habr.com/ru/post/673640/

юнит-тесты хорошо, ладно, но ломаются после изменения реализации (совсем как api!) и делают сложным рефакторинг, к тому же многие баги всё равно из-за взаимодействия с другим кодом. часто приходится выбрасывать, когда меняется код.

груг пишет юнит-тест в основном в начале проекта, помогает развитию, но не привыкай к ним и не ожидай долговременную пользу

сквозные тесты хорошие, показывают работу всей системы, но! сложно понимать когда ломаются и очень часто злят груга, иногда груг просто перестаёт обращать на них внимание потому что «ой, всегда ломаются» — очень плохо!

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

груг предпочитает немного юнит-тестов, особенно в начале, но тест не 100% всего кода и точно не «сначала тест». «тест по ходу дела» вполне подходит гругу, особенно пока груг разбирается в системе

груг пишет самые свирепые интеграционные тесты когда появляются точки разреза и система стабилизированная! api линии разреза обычно стабильнее реализации и интеграционный тест остаётся полезный много длинное время и легко отлаживать

оно идеальный набор теста для груга

closed

mentioned in merge request !1136 (merged)

mentioned in commit d1656ad5

mentioned in commit 3f6e637d

mentioned in commit 42a78834

mentioned in commit fa64059c