Ecrire des tests unitaires C avec RTRT (mode opératoire)

Rédigé par Dominique Mereaux le 10 mai 2014

Tout d'abord il faut créer un projet:



Il faudra ensuite sélectionner un TDP.Pour cela on configure au préalable des TDP (Target Deployement Configuration) qui décrivent l’environnement d’exécution :

  • Build
  • Compilateur
  • Instrumentation
  • Type de couverture
  • Etc.



Une fois le projet créé il faut rajouter des activités de test: component testing, system testing etc. Pour cela il faut afficher l'onglet start page:



Pour les tests unitaires on sélectionne "component testing". Ensuite il faudra sélectionner les sources comprenant les composants à tester.


Sur cette page on peut également modifier un certain nombre de paramètres pour la compilation ou l'exécution:



Par défaut le champ compute static metrics est coché. Des métriques de type statique telle que la complexité cyclomatique vont être calculées après analyse du code:



Le prochain écran permet de configurer la façon dont sera généré les scripts de test (format ptu) : prise en compte des valeurs aux limites, un ou plusieurs nœuds par composant testé ...



On peut lancer la génération des tests (fichier ptu)




On peut lancer l'exécution des tests (menu build)



Un rapport de test a été généré, mais pas seulement. On va trouver une mesure de couverture de code, des mesures de performances etc ...




En regardant la couverture on constate que les tests ne sont pas complets, pour cela il faudra modifier le ptu.


Classé dans : Non classé - Mots clés : aucun - aucun commentaire

Parametriser ses tests avec NUNIT

Rédigé par Dominique Mereaux le 06 mai 2014

Pour rendre ses tests automatiques maintenables il est essentiel de limiter le code de test. La plupart des framework de test offre la possibilité d'utiliser le même code source pour des jeux d'essais différents.



Prenons un exemple: sur une page web je veux tester la présence d'une série de lien:





Avec NUNIT on peut simplement rejouer le même test pour les différents liens:



Le test est rejoué pour les deux liens:


Le code suivant est équivalent:



Encore plus fort, si j'ai plusieurs paramètres je peux les combiner en utilisant en autres une stratégie de type "pairwise". Pour celà j'utilise l'attribut Pairwise de test. Voici un exemple:



Pairwise: au lieu d'avoir toutes les combinaisons de paramètres par 3, on se contente des combinaisons par paire: toutes les combinaisons de valeurs pour 2 paramètres sont présentes.


Et voici les combinaisons proposées:



Plus d'infos sur NUNIT

Classé dans : Automatisation, Outil de test - Mots clés : automatisation, NUNIT, framework de test - aucun commentaire

Tester ses activités avec la classe: ActivityInstrumentationTestCase2

Rédigé par Dominique Mereaux le 14 mars 2014

Cette classe permet de tester le cycle de vie d'une activité.
Elle hérite de la classe ActivityIntrumentationTestCase qui permet comme son nom l'indique d'instrumenter l'activité soit:
  • de contrôler le cycle de vie.
  • de simuler des intents.
  • de simuler des interaction utilisateur.


Rappel cycle de vie:



Dans un premier il faut démarrer l'activité. Cela est réalisé au moment su SetUp du test:


La fonction setActivityInitialTouchMode(false);permet de déactiver le mode tactile pour pouvoir utiliser l'envoi de caractères.
L'appel à mActivity = getActivity(); permet de démarrer l'activité. Tout est en place pour démarrer les tests.

Pour interagir avec l'interface de l'application il faut le faire dans le thread de l'application.

Une fois l'objet graphique initialisé, ici le spinner, il est possible de simuler les interactions avec des fonctions de type sendKeys. Et maintenant testons le cycle de vie:


Il faut récupérer l'objet instrumentation qui va nous permettre de tester le cycle de vie. Dans un premier temps on travaille sur l'activité, elle est ensuite mise en pause puis l'activité reçoit l'événement resume.
Le test va consister à vérifier que l'activité est dans l'état avant la mise en pause.

Plus d'information: ici

Classé dans : Automatisation, Outil de test - Mots clés : aucun - aucun commentaire

Utiliser lint pour une analyse statique de votre code Android

Rédigé par Dominique Mereaux le 13 mars 2014

Lint est un outil d'analyse statique qui permet de détecter des anomalies avant même d'entamer les tests unitaires. Pour pas cher il vous permettra de détecter des bugs potentiels.

Si vous télécharger le bundle de développement android il se trouve sous le répertoire Tools du sdk.

Il se lance en ligne de commande:



Le résultat est affiché directement dans la console mais il est possible de générer un rapport en utilisant l'option:

./lint --html report.html /Users/dominiquemereaux/Android/SpinnerTest
Regardons de plus près ce rapport:



Il m'informe que je n'ai pas précisé le SDK min et max que mon application est sensée supporter.
Il me donne également des conseils pour corriger:



Les problèmes détectés sont classés dans les catégories suivantes:
  • correctness
  • security
  • performance
  • usability
  • accessibility
  • internationalization


Vous trouverez la liste des problèmes détectés à cette adresse:
lien

Classé dans : Outil de test - Mots clés : android, analyse statique - aucun commentaire

Testlink 1.9.6 avec Mantis

Rédigé par Dominique Mereaux le 10 mai 2013

Avec cette nouvelle version de testlink il devient de plus en plus facile d'intégrer un gestionnaire d'anomalie.


Déjà sur la version précédente, plus besoin de configurer des fichiers. Tout se fait désormais avec une interface. Dans l'exemple qui suit j'ai utilisé l'interface SOAP.




Un certain nombre d'informations doivent être renseignées:

  • Des identifiants pour se connecter.
  • L'url d'accès à Mantis.
  • Le projet Mantis ainsi qu'une catégorie du projet.


Une fois configurée, il est possible de tester la connexion à la base:



En cliquant sur l'outil, la connexion est tentée, ici l'icone indique que le lien est mal configuré. Pour plus d'informations sur le problème, l'onglet event donne des logs et en particuliers les erreurs:



Une fois la correction effectuée le test de connexion donnera:



Voyons maintenant la partie déclaration d'anomalie. Pour cela nous avons besoin d'un test exécuté:



Deux possibilités:

  • Lier le test à une anomalie existante avec son Id.
  • Créer automatiquement une anomalie avec des informations de testlink.

Une fois l'anomalie créée le lien est en place au niveau de l'exécution du test et permet d'accéder à l'anomalie pour la modifier:


Coté Mantis on obtient:



Avec cette nouvelle version de testlink déclarer des anomalies devient un jeu d'enfant.

Classé dans : Outil de test - Mots clés : testlink anomalie - 2 commentaires

page 1 sur 9suivante»

Catégories

Archives

Mots clés

Derniers articles

Derniers commentaires