следуете ли вы этому предложению?
# russian
e
следуете ли вы этому предложению?
g
нет, имхо чем меньше шума в тестах, тем лучше. Поля private тоже не делаю.
g
Почему? понял, речь о тестах
e
я тоже, но если поменять тест в модуле, то возможно зависимые модули тоже будут перекомпилированы
g
это почему? Тест же leaf модуль. Не думаю что это хоть как то влияет на компиляцию в плане скорости
e
у меня есть модуль сеть
на него зависимы фича модули
я меняю только тест в сети
g
ну так фича модули же не зависят на тесты только на сеть
e
все модули будут инвалидированы
g
нет, тесты же отдельный модуль
e
ну в тестах фича можно достучать тест из сети
g
это как?
не должно
если явно нет зависимости
e
оке буду пробовать
не думаю что грейдл прямо помнит импорты из других модулей
g
ну т.е. это не то как Gradle работает по умолчавнию точно
test source set не становятся доступен как зависиомость, именно поэтому у него свой source set
e
забудем про тесты, есть класс в модуле, он публик, на него можно сослаться в зависимом модуле
g
когда не теситы то да
e
я попробовал и смог обратиться к тест классу из нижнего модуля
oke
похоже баг Андроид Студии
код валидный в ней, но компиляция не проходит
m
кажется, тесты — это классы, доступные в определённой конфигурации модуля, изменились — можно инвалидировать
e
Не понял 🙂
g
давайте по существу. Есть какие-то доказательства, что с internal в тестах будет меньше пересборок gradle?
g
Это учитывается при инкрементальной компиляции внутри модуля Но пока что нет compile avoidance поддержки Kotlin в Gradle, поэтому это никак положительно не влияет на пересборки между модулями, просто потому что все задетые модули (из графа зависимостей изменённого модуля) перезапускают компиляцию, вне зависимости поменялось ABI или нет. Но в 1.3.10 появилась первая версию тулы для того что бы из Котлин модуля экстрактить ABI, что первый шаг к тому что compile avoidance может появится в Котлин на Gradle и тогда это уже будет влиять. Но, так как тесты это в 99% случаев leaf модуль, то на него никто не зависит и даже внутри модуля, связей мало между тестами, то думаю это никак не влияет ни сейчас ни в будущем Но я могу ошибаться, это то как я понимаю текущую фичи компилятора, но не то что я это проверял
👍 1
m
кажется, тесты можно считать модулем только при выставленной галке create separate module per source set. Всегда её снимаю, сложилось впечатление, что с ней «ничо не работает».
g
это идеевские модули просто, их во время компиляции на самом деле нет, у Gradle там свои заморочки, модуль на тесты и код один, но test source set не становится доступен в зависимостях и компилируется он отдельно, поэтому считай свой модуль