Pascal Duvergé, ingénieur informaticien

petite liste de remarques sur les tests unitaires:

• tout code qui n'est pas testé va planter ( à coup sûr )
• le code de test est plus long que la classe à tester
• le code de test est plus long que le script utilisant la classe testée
• le code de test est un excellent exemple d'utilisation de la classe; il permet un gain de temps énorme pour l'écriture de scripts utilisant cette classe; il constitue une sorte de documentation du code
• si une classe est difficile à concevoir ( rôles des méthodes, interaction entre classes... ) elle sera difficile à tester
• un code simple = un test simple = une mise en production rapide

voici une liste, la plus exhaustive possible, de trucs & astuces pour migrer des données. enjoy!

_ travailler sur le minimum d'outils ou de bases ( moteur de DB ) différentes

jongler entre des fenêtres ou des syntaxes est une gymnastique usante et faisant perdre du temps lors de migration de données.
ex: pour migrer d'access vers SQL Server, je copie de manière brute les données d'access dans SQL Server, puis je travaille avec SQL Server

_ utiliser une base test

ça serait vraiment dommage de flinguer une base de production et de couper le service le temps de remonter une sauvegarde

_ utiliser des outils intégrés et enregistrer chaque traitement de donnée ( requête )

utiliser des lots, enregistrer chaque requête de traitement de données dans une procédure stockée; créer des procédures stockées par thèmes:
_ selon la nature des données ex: écritures comptables vs adresses postales
_ selon la nature des requetes ex: vidage de tables, traitement de chaines, migration de données

_ utiliser une table de traçage des événements

cette table tracage_migration aura une structure du type:
libelle ( varchar assez long )
valeur ( varchar ou entier ou autre )
date_ecriture ( format date / heure )
et cette table logguera chaque étape d'insertion/suppression de données.
La requete est du type:
INSERT INTO tracage_migration (libelle,valeur,date_ecriture)
SELECT 'numero. nom de l etape', count(id), NOW() FROM  une_table

avec ce traçage dans la procédure d'insertion de données, on peut détecter rapidement:
_ où ça plante: l'étape suivante n'est pas là
_ où ça buggue: on a un nombre de lignes erroné entre les étapes avant/après

_ vérifier la taille des données

des données trop longues ou trop courtes ( voire vides ) indiquent souvent une erreur dans le sens même de ces données
ex: un numéro de telephone de 20 caractères au lieu de 10

_ faire corriger les données erronées au fil de l'eau

il faut un interlocuteur qui connait le sens des données et peut les corriger. il convient de lui envoyer des identifiants de données et les données à corriger, avec un indice:
ex: vérifier le pays, sélectionner un seul des deux téléphones...

_ nettoyer la base de test entre chaque essai

à l'aide d'une procédure stockée, afin d'éviter les interférences, doublons et autres effets désastreux

comme Perrick, je m'interroge sur la pertinence de mes tests unitaires.

dans quelle mesure un test valide-t-il réellement ou suffisamment fortement le code?

un bon test ( ou un bon scenario de tests ) doit ( dans l'ordre ):
_ valider les erreurs triviales
_ valider le cas général qui fonctionne
_ valdier les cas particuliers connus
_ ne pas être affecté par des effets de bord
_ être relativement simple à étendre
_ de manière générale, tester entièrement la regle de gestion que le code doit respecter, regle de gestion au moment du codage, qui pourra évoluer par la suite ( qui évoluera par la suite )

qui dit test unitaire dit fonction unitaire: on ne peut tester, dans un premier temps, que ce qui est simple. ceci amène naturellement à simplifier son code ( code unitaire ) et éviter le code couteau suisse :
_ une fonction / méthode ( unitaire ) ne fait qu'une seule action, simple
_ ses valeurs de retours sont normées, définies par le programmeur: booléen, tableau, chaine de caractère ...

toutes les fonctions ne sont pas simples, mais en procédant de cette manière le programmeur écrit des fonctions plus complexes basées sur des fonctions simples ( qui fonctionnent ) . les bugs possibles du code ne sont plus situés au niveau le plus bas, d'où un gain de temps lors de leur traque.