Flutter-geolocator: Je déteste vraiment les méthodes statiques...

@jaumard J'avoue que ce n'était peut-être pas le meilleur choix que j'ai fait. Cependant, pour ma défense, la pratique courante en matière de test et d'architecture d'application en général suggère que vous ne devriez pas vous moquer de ce que vous ne possédez pas (plus de lecture ici ).

Ma suggestion serait d'écrire un wrapper autour du géolocalisateur et de se moquer du wrapper à la place.

Votre lien concerne plus TDD que les tests unitaires en général. De plus, si nous ne nous moquons pas, le test ne réussit pas, je suppose, car il n'y a pas d'implémentation dessus lors de l'exécution du test.

Aussi, je veux vérifier que la géolocalisation est appelée dans mon code et vérifier ce que je fais avec le résultat est correct. Autant de raisons pour lesquelles vous voulez vous moquer des tiers :)

Ne vous moquez pas non plus des deps en utilisant le réseau et exécutez vos tests sans réseau, ce sera amusant :D ou même avec vraiment montrer le réseau et obtenez 1 heure pour exécuter vos tests lol

Mais oui, je vais faire mon propre wrapper autour du géolocalisateur, en me demandant simplement si quelque chose a été intégré avant de le faire.

Le lien suggère également de créer des wrappers/adaptateurs/shims pour les dépendances tierces et de les simuler à la place, pour les raisons spécifiques que vous avez mentionnées. De cette façon, vous ne vous moquez que du code que vous possédez (car vous êtes le propriétaire des wrappers/adaptateurs/shims).

Cela a les avantages suivants :

• Extrait l'API tierce, ce qui facilite son remplacement si nécessaire ;
• Réduit la surface de l'API aux seules parties dont votre application a besoin, ce qui rend l'API plus facile à utiliser et à comprendre par rapport au reste de votre application ;
• Ne cassera pas tous vos tests lorsque l'API tierce changera.

Je ferme ce sujet, mais n'hésitez pas à poursuivre la discussion ;)