Est-ce que l'objet se moque beaucoup?

Question

Je suis curieux de savoir combien d’entre vous intègrent les moqueries d’objets (des frameworks tels que JMock, NMock, RhinoMocks et des frameworks de tests unitaires) dans votre processus de développement quotidien. Quelles sont vos expériences?

Vous voyez, je développe au-dessus d’une plate-forme SIG (systèmes d’information géographique), dans laquelle la plupart des travaux concernent une manière de traiter les données. Comme son modèle d'objet de données est assez complexe (beaucoup de nombreuses classes et interfaces, toutes basées sur COM), il est également assez difficile et lourd à simuler. Dans ce cas, les moqueries engendrent beaucoup de frais généraux lors de la rédaction de suites de tests. Je me demande s’il existe des personnes se trouvant dans une situation similaire ou si, en quoi le fait de se moquer (quelle que soit la situation dans laquelle vous vous trouvez) fonctionne pour vous.

Answer 1

Lors d’un projet récent sur lequel j’ai travaillé, nous avons largement utilisé des objets fantaisie dans notre approche de test unitaire. Le projet était 100% Java et de taille moyenne (environ 100 000 lignes de code non commenté). Il s’agissait d’une application de bureau basée sur Swing - et le seul moyen efficace de tester la logique de l’interface utilisateur consistait à utiliser une variante de MVC qui nous permettait d’utiliser des objets fictifs pour remplacer les classes d’interface utilisateur Swing utilisées pour les tests automatisés. Nous avons également beaucoup moqué dans le test de notre couche d'accès aux données (Hibernate / DAO).

Dans l’utilisation de l’interface utilisateur, les Mock étaient faciles et faciles à construire. Et la conception de l'application (Fowler Passive View) s'intègre facilement. Ce n'était pas le cas pour les simulacres utilisés pour tester la couche d'accès aux données. Mais je peux dire que cela en valait clairement la peine. En fait, la plupart des «efforts» visaient réellement à proposer une solution réutilisable qui minimise le travail qu'un développeur doit effectuer pour créer chaque modèle factice. Je vous recommande de prendre le temps de creuser et de découvrir une approche adaptée à votre situation qui vous permet de simuler facilement votre couche de données SIG. Ça - ou juste simuler manuellement chaque classe. Quoi qu’il en soit, il est utile d’exécuter les tests unitaires automatisés reposant sur des modèles.

Answer 2

Dans ma situation, les simulacres fonctionnent vraiment bien. Mais j'utilise Python, qui est tellement dynamique qu'il rend beaucoup de choses impliquant des tests beaucoup plus faciles.

Dans des situations comme la vôtre, lorsque l'application est principalement pilotée par les données (à ma connaissance), les simulacres peuvent ne pas être aussi utiles. Le simple fait de transmettre des données et de les regarder sortir devrait suffire pour les tests. Je voudrais simplement m'assurer que l'application est suffisamment modularisée pour que cette approche puisse être appliquée à des composants relativement petits.

Answer 3

Se moquer peut être utile dans une sorte de projet. Mais parfois, se moquer prend beaucoup de temps et son retour sur investissement est faible.

Answer 4

Essayer de tester Sharepoint semble être le seul moyen de se moquer, et seul typemock vous permettra de simuler classes scellées.

Answer 5

Les moqueries sont très utilisées dans mon cas. Les simulacres s'appliquent généralement aux classes ayant des dépendances externes, par exemple. réseau, base de données, système de fichiers. N'importe lequel de ceux-ci peut introduire des paillettes dans les tests si des simulacres ne sont pas utilisés.

Si les simulacres que vous trouvez coûteux à écrire car il y a beaucoup de fausses données à remplir, vous pouvez définir des objets de données pré-remplis comme constantes et les utiliser ou des copies légèrement modifiées dans votre test. Si de tels objets de données ont des dépendances externes, alors reformulez-les de manière à séparer les deux préoccupations.

Answer 6

Dave Bouman a lancé une initiative visant à créer une bibliothèque communautaire de Mocks à utiliser dans les tests unitaires liés à ArcObjects. Son blog et ce référentiel svn contiennent d'excellentes informations sur les systèmes de test SIG à tests unitaires

http://blog.davebouwman.net/CategoryView,category,Unit % 2BTesting.aspx

http://svn2.assembla.com/svn/arcdeveloper/TestingUtilities/ coffre /