Connector Builder test de soumission

Tout connecteur Workflows Okta publié sur le Okta Integration Network doit être correctement évalué afin de répondre aux standards rigoureuses attendues par les clients Okta.

Dans le cadre du processus de soumission, les tiers doivent remplir un document de cas de test et le soumettre avec les flux de test correspondants de leur connecteur.

Cas de test

Le document du cas de test explique :

Tous les scénarios de test
Leurs objectifs
Toutes les entrées requises
Résultats attendus

Les cas de test doivent couvrir les scénarios positifs et négatifs. Un scénario négatif est un cas de test dans lequel la carte échoue ou renvoie une erreur si une entrée requise est manquante ou si la carte reçoit une entrée non valide.

Les cas de test doivent détailler les combinaisons possibles des cartes de votre connecteur et prouver que les différentes options fonctionnent ensemble.

Exemples de cas de test

ID du cas de test	Carte d'action	Titre	Conditions nécessaires	Résultats attendus
TC001	Action d'API personnalisée	Créer un utilisateur avec un mot de passe et un paramètre d'activation égaux à false DEVRAIT renvoyer 200 ET définir le « Statut » de l'utilisateur sur « INTERMÉDIAIRE ».	Type de requête = `POST` URL liée = `/api/v1/users` Requête = `False`	L'utilisateur doit être créé avec le statut = `Staged`
TC002	Action d'API personnalisée	Activer un utilisateur avec un ID utilisateur valide, le paramètre sendEmail étant égal à false DEVRAIT renvoyer 200 ET définir le « Statut » de utilisateur sur « ACTIF »	Type de requête = `POST` URL liée = `/api/v1/users/lifecycle/activate`	Le statut de l'utilisateur passe à `Active`.
TC003	Action d'API personnalisée	Rechercher des utilisateurs par utilisateur e-mail DEVRAIT renvoyer 200 ET un tableau d'utilisateurs	Type de requête = `GET` URL liée = `/api/v1/users`	La liste des utilisateurs est affichée
TC004	Action d'API personnalisée	Suspendre un utilisateur avec un ID utilisateur valide et statut utilisateur « ACTIF » DEVRAIT renvoyer 200	Type de requête = `POST` URL liée = `/api/v1/users/lifecycle/activate`	Le statut de l'utilisateur doit passer à `Suspended`.
TC005	Action d'API personnalisée	Lire un utilisateur avec un ID utilisateur valide DEVRAIT renvoyer 200 ET les informations de utilisateur	Type de requête = `GET`	Les informations de l'utilisateur doivent être renvoyées
TC006	Action d'API personnalisée	Mettre à jour un utilisateur avec un ID utilisateur valide DEVRAIT renvoyer 200 ET les informations de utilisateur	Type de requête = `GET`	L'enregistrement de l'utilisateur est mis à jour
TC007	Action d'API personnalisée	Envoyer les mises à jour des données du groupe en mode push DEVRAIT renvoyer le code 200	Type de requête = `PUT`	Les données du groupe ont été mises à jour
TC008	Action d'API personnalisée	Obtenir les informations du groupe sans « / » au début de l'URL relative DEVRAIT renvoyer une erreur	Type de requête = `PUT`	La carte renvoie une erreur

Flux de test

L'équipe OIN utilise les flux de test fournis pour tester la fonctionnalité de votre connecteur et vérifier qu'il fonctionne comme prévu. L'équipe compare les résultats du test au document du cas de test fourni.

Exigences

Fournir un flux de test pour chaque cas de test.
Nommez chaque flux avec l'identifiant du cas de test et le nom de la carte d'action testée. Par exemple : TC001 Custom API Action
Les valeurs valides pour toutes les entrées d'une carte doivent être fournies dans le flux de test, y compris les valeurs obligatoires et non obligatoires.
Chaque combinaison d'entrées nécessite un flux de test. Par exemple, les cartes de recherche suivent généralement le schéma suivant : First Matching Record, First 200 Matching Records et Stream all Matching Records.
Vérifiez toutes les sorties de la carte par rapport aux valeurs attendues.
Incluez les flux de test par rapport aux entrées non valides, y compris les valeurs vides ou nulles. Utilisez la gestion des erreurs de la fonction If Error pour capturer l'erreur et la comparer à l'erreur attendue.

Exemple

Cet exemple de flux crée un utilisateur avec un mot de passe et un paramètre d'activation défini sur false. Il doit renvoyer un code de statut de 200 et définir le statut de l'utilisateur sur STAGED. Ce cas de test utilise les sections Try et If Error de la carte de fonction If Error :