2009-01-06 6 views
2

Je travaille sur un projet dont je ne sais vraiment pas comment tester un appareil. Il s'agit d'un cadre discret basé sur des balises pour le câblage des événements entre les modèles, les vues et les délégués dans un système GUI.Stratégie de test pour une application étendue avec peu de méthodes publiques?

Fondamentalement vous avez un grand fichier json qui est utilisé décrit tous les événements, les gestionnaires d'événements et les liaisons. L'utilisateur crée ses modèles, vues et délégués qui n'ont aucune connaissance du framework. Le fichier JSON est passé à une des méthodes init(), le cadre crée toutes les instances nécessaires et se charge de toutes les liaisons, les auditeurs, etc.

Les problèmes que j'ai sont deux fois:

1) Il n'y a fondamentalement qu'une seule méthode publique dans le framework, tout le reste est communiqué via le balisage dans le fichier JSON. Par conséquent, j'ai une très petite surface d'essai pour ce qui est une application grande et compliquée.

2) L'un des gros rôles de l'application est d'instancier les classes si elles n'ont pas été instanciées auparavant et mises en cache. Cela signifie que j'ai besoin de vraies classes dans mon code de test, de simples simulacres ne vont pas le couper.

En ce moment je considère un couple si des solutions. Le premier est de commencer à tester les méthodes privées. La seconde consiste à simplement remplacer les constructeurs.

Quelqu'un d'autre a des idées?

Répondre

1

listez les fonctionnalités (scénarios, cas d'utilisation, peu importe comment vous voulez les appeler) du système et établissez des données/cadres JSON pour chaque entité. Ce sont vos tests unitaires.

+0

Par cela je suppose que vous voulez dire rendre publiques les méthodes qui gèrent une partie spécifique du JSON, puis écrire des spécifications pour qu'elles ne transmettent que la partie du JSON qui les intéresse? – ChrisInCambo

+0

@ [ChrisInCambo] Je ne sais pas à ce niveau de détail Chris, je n'ai pas vu votre logiciel! ;-) D'après votre description, il semblerait que les données JSON servent de configuration générale pour tout le reste, alors modélisez les scénarios avec cela. –

2

1) Il est essentiellement une seule méthode publique dans le cadre, tout le reste est communiquée par la majoration dans le fichier JSON. Par conséquent, j'ai une très petite surface de test pour ce qui est une grande et application compliquée.

Comment est-ce possible? est ce cadre compliqué entier stocké dans une classe? s'il y a plusieurs classes impliquées, comment partagent-elles l'information sans méthodes publiques?

Un constructeur est aussi une méthode publique, d'ailleurs.

Vous contentez-vous de contourner l'objet JSON? cela couplerait votre cadre à la source d'information trop étroitement. Vous devriez avoir une classe analysant le JSON, et le reste communiquant sans connaissance de la source de données (via des méthodes publiques testables).

+0

Le cadre est contrôlé par des annotations et non par des appels de méthode, il existe évidemment des méthodes privées en coulisses qui sont chargées de traiter des sections spécifiques de cette majoration. Mais le fait est que je ne veux pas que les utilisateurs du framework aient un contrôle via une API. – ChrisInCambo

+0

Je suppose que cela se résume à devrais-je commencer à tester des méthodes privées pour élargir la surface testable? – ChrisInCambo

+0

Comment la classe communique-t-elle ses résultats? est-ce qu'il les persiste, les sérialise sur disque, envoie une requête http? Vous devez simuler l'interface de la sortie et voir si vous obtenez la sortie appropriée pour l'entrée correcte. Semblable à ce que Steven a suggéré. –

Questions connexes