Je vais écrire un nouveau point de terminaison pour déverrouiller l'objet de domaine, quelque chose comme:En utilisant les meilleures pratiques dans la configuration de test API - DB de communication nécessaire (TDD)
../domainObject/{id}/unlock
Comme je demande TDD, j'ai commencé écrire un test API en premier. Lorsque le test échoue, je vais commencer à écrire des tests d'intégration et d'unité et mettre en œuvre le code réel. Dans le test API, j'ai besoin de données de domaine verrouillées pour la configuration du dispositif de test pour tester le point de terminaison de déverrouillage qui sera créé. Toutefois, il n'existe aucun point de terminaison pour verrouiller l'objet de domaine sur le système. (Nos travaux Quartz verrouillent les données) Je veux dire, j'ai besoin de créer une donnée en utilisant directement la base de données.
Je sais que dans le test API, l'utilisation simple de la base de données n'est pas la meilleure pratique. Si vous avez besoin de données de test, vous devez également appeler l'API. par exemple.
../domainObject/{id}/lock
Ce scénario devrait-il être une exception dans ce cas? Ou y a-t-il d'autres pratiques que je devrais suivre?
Merci.
Je pense que dans certains scénarios, lorsque la configuration est particulièrement difficile/coûteuse, il est acceptable de s'appuyer sur certaines données de test, ou mieux encore - essayez de l'insérer via la porte dérobée. Autrement dit, lorsque vous testez (tout) un autre scénario que l'insertion/création réelle. Dans votre cas, il pourrait être ok, s'il n'y a aucun moyen de contrôler/envelopper la fonctionnalité Quartz (emplois) –
oui, l'utilisation de porte dérobée peut être acceptable, merci. Cependant, je n'ai pas créé de test d'api pour cette fonctionnalité car nous avons aussi des tests d'acceptation (sélénium), qui peuvent le couvrir. – skynyrd