Комментарии 9
Хотелось бы еще раскрыть тему деления на модули + ui тесты для них. Например, есть у вас три аппликейшн модуля - applicant, hr-mobile, design-gallery. Есть ui тесты в каждом из этих модулей в папке androidTest, которые относятся к конкретному апликейшену, есть ui фича от которой зависят все три апп модуля - надо написать ui тест для это фичи, вопрос куда поместить этот тест и можно ли общие тесты вынести в отдельный модуль? Интересует как вы пишете ui тесты для каждого апп модуля и что делаете, если нужно протестировать общую ui фичу от которой зависят несколько апп модулей?) Спасибо
Мы ui-тесты не выносим в отдельные модули. Допустим, тесты для applicant лежат в app-модуле этого приложения. Фичи достаточно сложно тестить в отрыве от контекста их использования. Фича может иметь внешние зависимости, несколько точек входа, и это все может сильно менять поведение фичи. Поэтому если фича покрывается ui-тестами, то в контексте конкретного приложения.
На самом деле у нас не так много общих ui-фичей между приложениями. В основном это какие-то общие core-модули для архитектурных компонентов, работа с data-слоем и пр. А этот код хорошо покрывается unit-тестами. А такие тесты уже складываем в конкретные модули этих компонентов.
как вы посчитали зависимости (критический путь) между модулями у себя в проекте? Руками или есть какой то инструмент?
Когда-то считали самописным Gradle-плагином в связке с https://github.com/cdsap/Talaiot, чтобы учитывать фактическое время сборки тасок, но сейчас эта фича есть в Gradle Build Scan (https://scans.gradle.com/). В build scan есть Timeline сборки и в поиске по нему можно поставить галочку "On critical path", чтобы подсветить участвующие в критическом пути таски. При этом для оценки критического пути важно запускать сборку с флагом --no-cache, чтобы исключить влияние кэша.
Полезная статья. Главное сильно не увлекаться вынесением общего кода между фичами, бывает сложно на начальном этапе выделить корректную абстракцию. И то, что кажется похожим и общим сейчас, может иметь тенденцию к расхождению по разным сторонам в будущем. Общий код != правильная абстракция, и иногда бывает даже лучше продублировать некоторые вещи, чем закинуть всё в Core модуль.
Первая проблема — если у нас большой проект, становится сложно ориентироваться в коде. Наше приложение — многомодульный проект, в котором несколько сотен модулей. Если сложить весь код в одну директорию, потеряться будет проще простого.
Очень странный абзац
Можно с той же структурой пакетов держать один модуль и проблемы ориентации в коде не будет
Как сложить код нескольких сотен модулей в одну директорию? Обычно код модуля и так лежит в отдельной директории
В остальном, хорошая статья, спасибо
@georgyRспасибо за статью, очень интересно! У меня 2 вопроса:
Можешь, пожалуйста, рассказать подробнее про sub-feature? А то ты перечислял типы модулей, а потом буквально вскользь написал про sub-feature. Но что это, и чем это отличается в feature?
Есть ли у вас механизм, как переиспользовать фичу в другой фиче? Например, есть фича на одном экране. И надо её точно также показать совершенно в другом. Как вы это делаете?
В разделе "Зачем делить большие фичи" как раз и идет речь о sub-feature. Из текста, конечно, это не очевидно получилось. По сути это обычные feature-модули, только они объединены общей бизнес-областью, и имею общие core-модули.
Да, конечно есть, без этого дальше 1-2 экранов не получилось бы навигироваться). У каждого модуля есть свой api. Допустим есть модуль c экраном
Resume
, api модуля содержит функциюgetNavScreen()
. У модуляResumeList
, который хочет открыть этот экран, есть зависимостьdeps
- интерфейс с функциейgetResumeNavScreen()
. Оба модуля подключены к app-модулю, поэтому мы через него можем реализовать зависимость модуляResumeList
и связать 2 фичи. Но это если в вкратце, подробно про связывание модулей можно почитать в https://habr.com/ru/company/hh/blog/566450/
Иерархия модулей: как выстроить связи между модулями в Android