Je ne suis pas ingénieur logiciel. Je suis doctorant dans le domaine des géosciences.
Il y a presque deux ans, j'ai commencé à programmer un logiciel scientifique. Je n'ai jamais utilisé l'intégration continue (CI), principalement parce qu'au début je ne savais pas qu'elle existait et j'étais la seule personne à travailler sur ce logiciel.
Maintenant que la base du logiciel fonctionne, d'autres personnes commencent à s'y intéresser et veulent contribuer au logiciel. Le plan est que d'autres personnes dans d'autres universités mettent en œuvre des ajouts au logiciel de base. (J'ai peur qu'ils puissent introduire des bugs). De plus, le logiciel est devenu assez complexe et est devenu de plus en plus difficile à tester et je prévois également de continuer à travailler dessus.
Pour ces deux raisons, je pense de plus en plus à l'utilisation de CI. Comme je n'ai jamais reçu de formation d'ingénieur logiciel et que personne autour de moi n'a jamais entendu parler de CI (nous sommes des scientifiques, pas de programmeurs), j'ai du mal à démarrer mon projet.
J'ai quelques questions où j'aimerais obtenir des conseils:
Tout d'abord une brève explication du fonctionnement du logiciel:
Le logiciel est contrôlé par un fichier .xml contenant tous les paramètres requis. Vous démarrez le logiciel en passant simplement le chemin d'accès au fichier .xml comme argument d'entrée et il s'exécute et crée quelques fichiers avec les résultats. Un seul passage peut prendre environ 30 secondes.
C'est un logiciel scientifique. Presque toutes les fonctions ont plusieurs paramètres d'entrée, dont les types sont principalement des classes assez complexes. J'ai plusieurs fichiers .txt avec de gros catalogues qui sont utilisés pour créer des instances de ces classes.
Venons-en maintenant à mes questions:
tests unitaires, tests d'intégration, tests de bout en bout? : Mon logiciel compte maintenant environ 30 000 lignes de code avec des centaines de fonctions et environ 80 classes. Cela me semble un peu étrange de commencer à écrire des tests unitaires pour des centaines de fonctions qui sont déjà implémentées. J'ai donc pensé à créer simplement des cas de test. Préparez 10 à 20 fichiers .xml différents et laissez le logiciel s'exécuter. Je suppose que c'est ce qu'on appelle des tests de bout en bout? Je lis souvent que vous ne devriez pas faire cela, mais peut-être que c'est ok comme début si vous avez déjà un logiciel qui fonctionne? Ou est-ce simplement une idée stupide d'essayer d'ajouter CI à un logiciel déjà fonctionnel.
Comment écrivez-vous des tests unitaires si les paramètres de fonction sont difficiles à créer? supposons que j'ai une fonction
double fun(vector<Class_A> a, vector<Class_B>)
et généralement, je devrais d'abord lire dans plusieurs fichiers texte pour créer des objets de typeClass_A
etClass_B
. J'ai pensé à créer des fonctions factices commeClass_A create_dummy_object()
sans lire les fichiers texte. J'ai aussi pensé à implémenter une sorte de sérialisation . (Je ne prévois pas de tester la création des objets de classe car ils ne dépendent que de plusieurs fichiers texte)Comment écrire des tests si les résultats sont très variables? Mon logiciel utilise de grandes simulations de monte-carlo et fonctionne de manière itérative. Habituellement, vous avez ~ 1000 itérations et à chaque itération, vous créez ~ 500-20 000 instances d'objets basées sur des simulations de monte-carlo. Si un seul résultat d'une itération est un peu différent, toutes les itérations à venir sont complètement différentes. Comment gérez-vous cette situation? Je suppose que c'est un gros point contre les tests de bout en bout, car le résultat final est très variable?
Tout autre conseil avec CI est très apprécié.