Après une migration récente vers Dagger 2, l'application sur laquelle je travaille utilise @ActivityScope pour chaque fonction. Chaque fonctionnalité d'application est implémentée à l'aide du modèle MVP et dispose de sa propre configuration Composant dague locale qui dépend du composant Application pour les dépendances requises pendant tout le cycle de vie de l'application (fourni par l'application). L'activité de chaque fonctionnalité étend une classe de base qui fournit le composant d'application principal à une méthode qui est surchargée par chaque activité afin de configurer le composant dagger local (construit le composant local et instancie le module local).Test expresso avec Dagger 2 et portées personnalisées
Le problème que j'essaie de résoudre est de savoir comment injecter des mocks dans l'activité testée. Le principal problème que je rencontre est que je ne peux pas permuter le composant local d'origine et le module correspondant avec des composants simulés lors de l'exécution. Il y a beaucoup d'articles sur les tests Espresso avec Dagger 2 que je lis, mais ils ne font pas la promotion d'une architecture propre. Pour la plupart, ils s'appuient sur l'AppComponent pour injecter toutes les activités, alors que dans mon cas, le composant de chaque fonctionnalité est responsable de l'injection de sa propre activité. Jusqu'à présent, la meilleure approche que j'ai trouvée a été d'introduire un générateur de composants qui n'est initialisé que dans le cadre de la configuration du test et dans le code d'activité pour l'initialiser, sinon configurer le composant réel. Cependant, je suis réticent à mélanger la production et le code de test. Voici un schéma qui représente la configuration Dagger: Dagger 2 Setup
