Diagnostic et tests des vues

Statut documentaire : guide — voir Maturité et preuves.

Les pannes de vues se diagnostiquent plus facilement lorsque modèle, cache de page, couche d’événements locale et rendu sont testés séparément.

Ordre de diagnostic

1. Vérifier que modèle/package/vue sont chargés.
2. Vérifier la cible ClassItem/ObjectItem et la collection.
3. Vérifier la résolution des noms DataSet, DataSource et DataCursor.
4. Vérifier le curseur et l’objet courant.
5. Vérifier le binding du composant fonctionnel vers la surface prévue.
6. Vérifier que le PageControler possède le composant/frame.
7. Vérifier les mappings d’événements ObjectBehind/PageModel.
8. Vérifier si l’événement est local, routé au parent, applicatif ou métier/processus.
9. Ensuite seulement diagnostiquer provider, RPC, service, persistance ou rendu spécifique.

Diagnostics à exposer

Pour une vue réutilisable, journaliser ou exposer : nom de vue, nom de composant fonctionnel, identifiant d’implémentation concrète si utile, noms DataSet/DataSource/Cursor, classe d’événement, source/sender, identité de l’objet courant, état provider et cible d’escalade. Les dépendances absentes doivent échouer visiblement plutôt que silencieusement.

Tests

Tester le chargement des métadonnées de vue, résolution des surfaces de données, propagation master-detail, annulation before-post, refresh dépendant after-post, consommation des événements locaux, escalade explicite vers les actions, routage parent/enfant, gardes anti-boucle et remplacement local/distant du provider.

Pour le web, tester aussi nettoyage des subscriptions, séparation de l’état local, debounce/batching, états loading/error/offline et absence d’appel distant inattendu pour un événement purement local.

Critère d’acceptation

Une vue est correctement factorisée lorsque le même modèle conceptuel peut être projeté via une autre implémentation de rendu et que le même composant fonctionnel peut être alimenté par un autre provider sans redéfinir la sémantique métier.