Frappe Framework
Écrire des tests
Le mode développeur pose déjà test_{doctype}.py. Les commandes bench se testent avec BaseTestCommands. Le parallèle découpe les fichiers ou passe par un orchestrateur.
Règles
Le fichier commence par test_ et finit en .py, n’importe où dans le dépôt. Le lanceur construit les enregistrements des DocTypes liés par un Link. Hors DocType, un test unitaire simple garde le même préfixe. Le détail des cas DocType est dans Tests unitaires.
En mode développeur, créer un DocType produit test_{doctype}.py. Le fichier crée et nettoie les dépendances. L’exemple, tiré de test_event.py, hérite de unittest.TestCase, pas de FrappeTestCase. create_events insère « _Test Event 1 » et « _Test Event 3 », Public, au 2014-01-01, le troisième avec [email protected] dans event_individuals. La virgule entre event_type et event_individuals manque dans le texte publié. test_not_allowed_private charge pourtant « _Test Event 2 », que cet extrait ne crée pas. setUp appelle create_events, tearDown remet Administrator.
Commandes bench
Une classe qui étend BaseTestCommands (frappe.tests.test_commands) et unittest.TestCase part avec bench run-tests. L’exemple test_execute : frappe.db.get_database_size a un code 0 et un stdout convertible en float. frappe.local.site a un code 1 et un stderr non vide. frappe.bold avec --kwargs échappé ({{"text": "DocType"}}, pour que .format ne mange pas les accolades) a un code 0, et self.stdout[1:-1] égale frappe.bold(text='DocType'), guillemets retirés.
Lancer
D’abord bench setup requirements --dev, à cause des dev-requirements.txt. Puis, depuis frappe_bench :
| Commande | Cible |
|---|---|
bench --site [sitename] run-tests | Tout |
--app frappe | Une application |
--doctype "Task" | Un DocType |
--module-def "Contacts" | Tous les DocTypes d’une Module Def |
--module frappe.tests.test_api | Un chemin de module |
--test test_insert_many | Un cas, avec --module |
--skip-test-records | Sans enregistrements de test |
--profile | Rapport après coup. L’exemple Task affiche 1 test et 9133 appels, tableau coupé |
--verbose | Journal plus bavard, placé avant run-tests |
frappe.in_test dit si le code tourne dans un test. Sur les anciennes versions, frappe.flags.in_test, qui sera déprécié. L’exemple n’appelle notify_error_to_user() que si ce n’est pas un test.
En parallèle
run-parallel-tests répartit sur plusieurs machines d’intégration continue. La signature publiée a --build-id et --total-build. Les exemples d’usage écrivent --total-builds. Deux instances : build-id 1 et 2, total 2. La liste des fichiers est coupée en deux, première moitié puis seconde.
Avec --use-orchestrator, les deux instances lancent la même commande. Il faut CI_BUILD_ID, identifiant unique du build, et ORCHESTRATOR_URL, URL publique de test-orchestrator. Le prochain fichier part quand une instance est libre.
Quatre fichiers de 4, 2, 1 et 1 minutes : 8 minutes en série, 6 si on coupe la liste en deux (4+2 contre 1+1), 4 si l’orchestrateur laisse les trois courts à la seconde instance pendant que la première est occupée 4 minutes. La page se termine par des balises échappées total-number-of-builds et build-number, sans autre commande.
Point d’attention
Le test privé de l’exemple cherche un Event 2 que create_events ne crée pas dans cette page. --total-build et --total-builds figurent tous les deux.