В разделе "Зачем делить большие фичи" как раз и идет речь о 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/
Мы ui-тесты не выносим в отдельные модули. Допустим, тесты для applicant лежат в app-модуле этого приложения. Фичи достаточно сложно тестить в отрыве от контекста их использования. Фича может иметь внешние зависимости, несколько точек входа, и это все может сильно менять поведение фичи. Поэтому если фича покрывается ui-тестами, то в контексте конкретного приложения.
На самом деле у нас не так много общих ui-фичей между приложениями. В основном это какие-то общие core-модули для архитектурных компонентов, работа с data-слоем и пр. А этот код хорошо покрывается unit-тестами. А такие тесты уже складываем в конкретные модули этих компонентов.
В разделе "Зачем делить большие фичи" как раз и идет речь о 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/Мы ui-тесты не выносим в отдельные модули. Допустим, тесты для applicant лежат в app-модуле этого приложения. Фичи достаточно сложно тестить в отрыве от контекста их использования. Фича может иметь внешние зависимости, несколько точек входа, и это все может сильно менять поведение фичи. Поэтому если фича покрывается ui-тестами, то в контексте конкретного приложения.
На самом деле у нас не так много общих ui-фичей между приложениями. В основном это какие-то общие core-модули для архитектурных компонентов, работа с data-слоем и пр. А этот код хорошо покрывается unit-тестами. А такие тесты уже складываем в конкретные модули этих компонентов.