Le problème de synchronisation apparaît chaque fois que des stratégies de test sont discutées. Fondamentalement - en raison de la charge supplémentaire que les mokas créent pour les développeurs et également des risques de divergence entre les mooks et les dépendances réelles.
Alors, en quoi cela nous coûte-t-il moins cher d'assurer la synchronisation des mokas avec des implémentations réelles?
Pour la synchronisation, nous pouvons écrire un test qui effectue les mêmes vérifications par rapport à mok et à la mise en œuvre réelle.
Cela ressemble à ceci (j'écris sans DI, mais avec DI c'est plus simple et plus correct):
public abstract class AbstractValidOrderDaoTest(){ Dao dao; public abstract arrange(); @Test public void whenValidOrderInDb_thenReturnValidOrder(){ arrange(); Order order = dao.retrieve(); assertNotNull(order); assertNotNull(order.getCustomerName());
OrderDaoTest fonctionne contre un objet réel avec une maquette ou une dépendance réelle sous-jacente, tandis que ValidOrderDaoTest fonctionne contre une maquette.
Si ValidOrderDataSource est une vraie base de données, alors OrderDaoTest sera dans un package séparé et exécuté dans le cadre des tests d'intégration, qui peuvent se bloquer de temps en temps lors de la mise à jour de la base de données, par exemple. Cela ne devrait pas interférer avec CI \ CD.
Si ValidOrderDataSource est une base de données factice, OrderDaoTest s'exécutera avec le reste des tests unitaires.
Étant donné que la synchronisation Mock implique de tester une classe réelle, alors pour
la vraie classe devra barboter ses dépendances sous-jacentes. De plus, la dépendance au Mok sous-jacente devrait se comporter conformément au scénario du Mok sus-jacent. Dans notre cas, cela
ValidOrderDataSource.
Si vous y réfléchissez, cela a du sens - toute déclaration sur le comportement des classes supérieures implique implicitement un scénario dans les classes sous-jacentes. Si le contrôleur retourne quelque chose du service, ce serait bien si la base pouvait le fournir.
À l'inverse, les classes supérieures vivent souvent avec des idées irréalistes sur les classes inférieures, il n'est donc pas mauvais de supprimer des scripts inutiles.
La récursivité suggère que pour synchroniser la maquette de niveau supérieur, vous devez démarrer la synchronisation de toutes les simulations sous-jacentes jusqu'aux dépendances externes.
Cela rend la spécification du système encore plus transparente, car les scénarios plus généraux et abstraits reposent sur des scénarios plus privés.
Notez également qu'il existe des mokas qui n'ont pas besoin d'être synchronisés. C'est-à-dire nous n'avons pas une telle implémentation réelle qui devrait être vérifiée. Cela s'applique aux scénarios d'erreur majeurs. EmptyResultException_Datasource par exemple Cela réduit considérablement le nombre de tests croisés nécessaires.
La synchronisation est certainement nécessaire pour de véritables dépendances externes, telles que les files d'attente, les services externes, les bases de données - en particulier en ce qui concerne les données qu'elles prennent et retournent.
Si le service externe change soudainement, ce qui est souvent au stade de développement, nous n'avons aucun moyen de vérifier son comportement si nous n'écrivons pas de test de synchronisation.
En termes d'intensité de travail. En soi, nous avons déjà un vrai test de classe avec quelques dépendances arbitraires. Par rapport aux tests non synchronisés, nous devons faire quelques choses.
- mettre en évidence agir et affirmer dans un test abstrait
- faire un test spécifique pour moka
- correction des fausses dépendances dans un test de classe réel
- si vous le souhaitez, effectuez une répétition récursive complète jusqu'aux dépendances externes.