intégration continue pour les logiciels scientifiques

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:

1. 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.

2. 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 type Class_Aet Class_B. J'ai pensé à créer des fonctions factices comme Class_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)

3. 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é.

Tester un logiciel scientifique est difficile, à la fois à cause du sujet complexe et à cause des processus de développement scientifique typiques (aka. Pirater jusqu'à ce qu'il fonctionne, ce qui n'aboutit généralement pas à une conception testable). C'est un peu ironique étant donné que la science doit être reproductible. Ce qui change par rapport au logiciel «normal» n'est pas de savoir si les tests sont utiles (oui!), Mais quels types de tests sont appropriés.

Gestion de l'aléatoire: toutes les exécutions de votre logiciel DOIVENT être reproductibles. Si vous utilisez des techniques de Monte Carlo, vous devez permettre de fournir une graine spécifique pour le générateur de nombres aléatoires.

• Il est facile de l'oublier, par exemple lors de l'utilisation de la rand()fonction de C qui dépend de l'état global.
• Idéalement, un générateur de nombres aléatoires est transmis en tant qu'objet explicite via vos fonctions. L'en random-tête de bibliothèque standard de C ++ 11 rend cela beaucoup plus facile.
• Au lieu de partager un état aléatoire entre les modules du logiciel, j'ai trouvé utile de créer un deuxième RNG qui est ensemencé par un nombre aléatoire à partir du premier RNG. Ensuite, si le nombre de demandes au RNG par l'autre module change, la séquence générée par le premier RNG reste la même.

Les tests d'intégration sont parfaitement bien. Ils sont bons pour vérifier que les différentes parties de votre logiciel fonctionnent correctement ensemble et pour exécuter des scénarios concrets.

• Un niveau de qualité minimum «ça ne plante pas» peut déjà être un bon résultat de test.
• Pour des résultats plus solides, vous devrez également vérifier les résultats par rapport à une base de référence. Cependant, ces contrôles devront être quelque peu tolérants, par exemple tenir compte des erreurs d'arrondi. Il peut également être utile de comparer des statistiques récapitulatives au lieu de lignes de données complètes.
• Si la vérification par rapport à une ligne de base est trop fragile, vérifiez que les sorties sont valides et satisfont à certaines propriétés générales. Ceux-ci peuvent être généraux («les emplacements sélectionnés doivent être distants d'au moins 2 km») ou spécifiques au scénario, par exemple «un emplacement sélectionné doit se trouver dans cette zone».

Lors de l'exécution de tests d'intégration, il est judicieux d'écrire un exécuteur de test en tant que programme ou script distinct. Ce lanceur de test effectue la configuration nécessaire, exécute l'exécutable à tester, vérifie tous les résultats et nettoie ensuite.

Les vérifications de style de test unitaire peuvent être assez difficiles à insérer dans un logiciel scientifique car le logiciel n'a pas été conçu pour cela. En particulier, les tests unitaires deviennent difficiles lorsque le système testé a de nombreuses dépendances / interactions externes. Si le logiciel n'est pas purement orienté objet, il n'est généralement pas possible de simuler / stub ces dépendances. J'ai trouvé préférable d'éviter largement les tests unitaires pour de tels logiciels, à l'exception des fonctions mathématiques pures et des fonctions utilitaires.

Même quelques tests valent mieux qu'aucun test. Combiné avec la vérification «il faut compiler», c'est déjà un bon début pour une intégration continue. Vous pouvez toujours revenir et ajouter plus de tests plus tard. Vous pouvez ensuite hiérarchiser les zones du code qui sont plus susceptibles de se casser, par exemple parce qu'elles obtiennent plus d'activité de développement. Pour voir quelles parties de votre code ne sont pas couvertes par les tests unitaires, vous pouvez utiliser des outils de couverture de code.

Test manuel: Surtout pour les domaines problématiques complexes, vous ne pourrez pas tout tester automatiquement. Par exemple, je travaille actuellement sur un problème de recherche stochastique. Si je teste que mon logiciel produit toujours le même résultat, je ne peux pas l'améliorer sans casser les tests. Au lieu de cela, j'ai facilité les tests manuels : j'exécute le logiciel avec une graine fixe et j'obtiens une visualisationdu résultat (selon vos préférences, R, Python / Pyplot et Matlab permettent tous d'obtenir facilement des visualisations de haute qualité de vos ensembles de données). Je peux utiliser cette visualisation pour vérifier que les choses ne se sont pas vraiment mal passées. De même, le suivi de la progression de votre logiciel via la sortie de journalisation peut être une technique de test manuel viable, du moins si je peux sélectionner le type d'événements à consigner.

Cela me semble un peu étrange de commencer à écrire des tests unitaires pour des centaines de fonctions qui sont déjà implémentées.

Vous voudrez (généralement) écrire les tests lorsque vous modifiez lesdites fonctions. Vous n'avez pas besoin de vous asseoir et d'écrire des centaines de tests unitaires pour les fonctions existantes, ce serait (en grande partie) une perte de temps. Le logiciel fonctionne (probablement) correctement tel quel. Le but de ces tests est de s'assurer que les changements futurs ne cassent pas l'ancien comportement. Si vous ne changez plus jamais une fonction particulière, cela ne vaudra probablement jamais la peine de prendre le temps de la tester (car elle fonctionne actuellement, a toujours fonctionné et continuera probablement à fonctionner). Je recommande de lire Travailler efficacement avec le code héritépar Michael Feathers sur ce front. Il a d'excellentes stratégies générales pour tester des choses qui existent déjà, y compris des techniques de rupture de dépendance, des tests de caractérisation (sortie de fonction copier / coller dans la suite de tests pour vous assurer de maintenir un comportement de régression), et bien plus encore.

Comment écrivez-vous des tests unitaires si les paramètres de fonction sont difficiles à créer?

Idéalement, non. Au lieu de cela, vous rendez les paramètres plus faciles à créer (et par conséquent rendez votre conception plus facile à tester). Certes, les modifications de conception prennent du temps, et ces remaniements peuvent être difficiles sur des projets hérités comme le vôtre. TDD (Test Driven Development) peut vous y aider. Si les paramètres sont très difficiles à créer, vous aurez beaucoup de mal à écrire des tests dans un style test-first.

À court terme, utilisez des simulacres, mais méfiez-vous des moqueries de l'enfer et des problèmes qui les accompagnent à long terme. En grandissant en tant qu'ingénieur logiciel, cependant, j'ai réalisé que les simulacres sont presque toujours une mini-odeur qui essaient de résumer un problème plus important et de ne pas résoudre le problème principal. J'aime l'appeler "emballage de crotte", parce que si vous mettez un morceau de papier d'aluminium sur un peu de caca de chien sur votre tapis, ça pue toujours. Ce que vous avez à faire, c'est de vous lever, de ramasser la merde et de la jeter à la poubelle, puis de sortir la poubelle. C'est évidemment plus de travail, et vous risquez d'avoir des matières fécales sur vos mains, mais mieux pour vous et votre santé à long terme. Si vous continuez à emballer ces caca, vous ne voudrez pas vivre plus longtemps dans votre maison. Les simulacres sont de nature similaire.

Par exemple, si votre Class_Afichier est difficile à instancier car vous devez lire 700 fichiers, vous pouvez simplement vous moquer de lui. La prochaine chose que vous savez, votre maquette devient obsolète, et le réel Class_A fait quelque chose de très différent de la simulation, et vos tests passent toujours même s'ils devraient échouer. Une meilleure solution consiste à décomposer Class_Aen composants plus faciles à utiliser / tester et à tester ces composants à la place. Peut-être écrire un test d'intégration qui frappe réellement le disque et s'assurer que cela Class_Afonctionne dans son ensemble. Ou peut-être simplement avoir un constructeur pour Class_Acela que vous pouvez instancier avec une simple chaîne (représentant vos données) au lieu d'avoir à lire à partir du disque.

Comment écrire des tests si les résultats sont très variables?

Quelques conseils:

1) Utilisez des inverses (ou plus généralement, des tests basés sur les propriétés). De quoi s'agit-il [1,2,3,4,5]? Aucune idée. Quoi ifft(fft([1,2,3,4,5]))? Devrait l'être [1,2,3,4,5](ou près de lui, des erreurs en virgule flottante pourraient survenir).

2) Utilisez des assertions «connues». Si vous écrivez une fonction de déterminant, il peut être difficile de dire quel est le déterminant d'une matrice 100x100. Mais vous savez que le déterminant de la matrice d'identité est 1, même si c'est 100x100. Vous savez également que la fonction doit retourner 0 sur une matrice non inversible (comme un 100x100 plein de tous les 0).

3) Utilisez des assertions grossières au lieu d' assertions exactes . Il y a quelque temps, j'ai écrit du code qui enregistrait deux images en générant des points de liaison qui créent un mappage entre les images et en effectuant une déformation entre elles pour les faire correspondre. Il pourrait s'inscrire à un niveau sous-pixel. Comment pouvez-vous le tester? Des choses comme:

EXPECT_TRUE(reg(img1, img2).size() < min(img1.size(), img2.size()))

puisque vous ne pouvez vous inscrire que sur des parties qui se chevauchent, l'image enregistrée doit être plus petite ou égale à votre plus petite image), et aussi:

scale = 255
EXPECT_PIXEL_EQ_WITH_TOLERANCE(reg(img, img), img, .05*scale)

car une image enregistrée sur elle-même devrait être proche de elle-même, mais vous pourriez rencontrer un peu plus que des erreurs en virgule flottante en raison de l'algorithme à portée de main, alors vérifiez simplement que chaque pixel est à +/- 5% de la plage valide (0-255 est une gamme commune, niveaux de gris). Doit au moins être de la même taille. Vous pouvez même simplement tester la fumée (c'est-à-dire l'appeler et vous assurer qu'elle ne plante pas). En général, cette technique est meilleure pour les tests plus volumineux où le résultat final ne peut pas être (facilement) calculé a priori avant d'exécuter le test.

4) Utilisez OU STORE une graine de nombre aléatoire pour votre RNG.

Runs ne doivent être reproductibles. Il est faux, cependant, que la seule façon d'obtenir une exécution reproductible est de fournir une graine spécifique à un générateur de nombres aléatoires. Parfois, les tests de hasard sont précieux . J'ai vu des bogues dans le code scientifique qui surviennent dans des cas dégénérés générés de manière aléatoire . Au lieu d' appeler toujours votre fonction avec la même graine, générez une graine aléatoire , puis utilisez cette graine et enregistrez la valeur de la graine. De cette façon, chaque exécution a une graine aléatoire différente , mais si vous obtenez un plantage, vous pouvez réexécuter le résultat en utilisant la graine que vous avez enregistrée pour déboguer. J'ai effectivement utilisé cela dans la pratique et cela a corrigé un bug, alors j'ai pensé que je le mentionnerais.Inconvénient: vous devez enregistrer vos cycles de test. À l'envers: correction et correction des bogues.

HTH.

1. Types de test

   • Cela me semble étrange de commencer à écrire des tests unitaires pour des centaines de fonctions qui sont déjà implémentées

     Pensez-y à l'envers: si un patch touchant plusieurs fonctions rompt l'un de vos tests de bout en bout, comment allez-vous déterminer lequel est le problème?

     Il est beaucoup plus facile d'écrire des tests unitaires pour des fonctions individuelles que pour l'ensemble du programme. Il est beaucoup plus facile d'être sûr d'avoir une bonne couverture d'une fonction individuelle. Il est beaucoup plus facile de refactoriser une fonction lorsque vous êtes sûr que les tests unitaires détecteront tous les cas de coin que vous avez cassés.

     L'écriture de tests unitaires pour des fonctions déjà existantes est parfaitement normale pour quiconque a travaillé sur une base de code héritée. Ils sont un bon moyen de confirmer votre compréhension des fonctions en premier lieu et, une fois écrits, ils sont un bon moyen de trouver des changements de comportement inattendus.

   • Les tests de bout en bout valent également la peine. S'ils sont plus faciles à écrire, faites-les d'abord et ajoutez des tests unitaires ad hoc pour couvrir les fonctions que vous craignez le plus pour les autres. Vous n'êtes pas obligé de tout faire en même temps.

   • Oui, l'ajout de CI au logiciel existant est raisonnable et normal.

2. Comment écrire des tests unitaires

   Si vos objets sont vraiment chers et / ou complexes, écrivez des simulacres. Vous pouvez simplement lier les tests à l'aide de simulations séparément des tests à l'aide d'objets réels, au lieu d'utiliser le polymorphisme.

   Vous devriez de toute façon avoir un moyen facile de créer des instances - une fonction pour créer des instances factices est courante - mais avoir des tests pour le processus de création réel est également judicieux.

3. Résultats variables

   Vous devez avoir des invariants pour le résultat. Testez-les plutôt qu'une seule valeur numérique.

   Vous pouvez fournir un faux générateur de nombres pseudo-aléatoires si votre code de monte-carlo l'accepte comme paramètre, ce qui rendrait les résultats prévisibles au moins pour un algorithme bien connu, mais il est fragile à moins qu'il ne retourne littéralement le même nombre à chaque fois.

1. Ce n'est jamais une idée stupide d'ajouter CI. Par expérience, je sais que c'est la voie à suivre lorsque vous avez un projet open source où les gens sont libres de contribuer. CI vous permet d'empêcher les gens d'ajouter ou de modifier du code si le code rompt votre programme, il est donc presque inestimable d'avoir une base de code fonctionnelle.

   Lorsque vous envisagez des tests, vous pouvez certainement fournir des tests de bout en bout (je pense que c'est une sous-catégorie de tests d'intégration) pour être sûr que votre flux de code fonctionne comme il se doit. Vous devez fournir au moins quelques tests unitaires de base pour vous assurer que les fonctions génèrent les bonnes valeurs, dans le cadre des tests d'intégration peuvent compenser les autres erreurs commises pendant le test.

2. La création d'objets de test est quelque chose d'assez difficile et laborieux. Vous avez raison de vouloir fabriquer des objets factices. Ces objets devraient avoir des valeurs par défaut, mais en cas de bord, pour lesquelles vous savez certainement quelle devrait être la sortie.

3. Le problème avec les livres sur ce sujet est que le paysage de CI (et d'autres parties de devops) évolue si rapidement que tout dans un livre sera probablement obsolète quelques mois plus tard. Je ne connais aucun livre qui pourrait vous aider, mais Google devrait, comme toujours, être votre sauveur.

4. Vous devez exécuter vos tests vous-même plusieurs fois et effectuer une analyse statistique. De cette façon, vous pouvez implémenter certains cas de test où vous prenez la médiane / moyenne de plusieurs exécutions et la comparez à votre analyse, pour savoir quelles valeurs sont correctes.

Quelques conseils:

• Utilisez l'intégration des outils CI dans votre plate-forme GIT pour empêcher le code cassé d'entrer dans votre base de code.
• arrêtez la fusion du code avant que l'examen par les pairs n'ait été effectué par d'autres développeurs. Cela rend les erreurs plus facilement connues et empêche à nouveau le code cassé d'entrer dans votre base de code.

Dans une réponse avant amon déjà mentionné quelques points très importants. Permettez-moi d'en ajouter un peu plus:

1. Différences entre le développement de logiciels scientifiques et les logiciels commerciaux

Pour les logiciels scientifiques, l'accent est normalement mis sur le problème scientifique, bien sûr. Les problèmes consistent davantage à gérer le contexte théorique, à trouver la meilleure méthode numérique, etc. Le logiciel n'est qu'une, plus ou moins, petite partie du travail.

Le logiciel est dans la plupart des cas écrit par une ou seulement quelques personnes. Il est souvent écrit pour un projet spécifique. Lorsque le projet est terminé et que tout est publié, dans de nombreux cas, le logiciel n'est plus nécessaire.

Les logiciels commerciaux sont généralement développés par de grandes équipes sur une période plus longue. Cela nécessite beaucoup de planification pour l'architecture, la conception, les tests unitaires, les tests d'intégration, etc. Cette planification nécessite beaucoup de temps et d'expérience. Dans un environnement scientifique, il n'y a normalement pas de temps pour cela.

Si vous souhaitez convertir votre projet en un logiciel similaire à un logiciel commercial, vous devez vérifier les points suivants:

• Avez-vous le temps et les ressources?
• Quelle est la perspective à long terme du logiciel? Que se passera-t-il avec le logiciel lorsque vous aurez terminé votre travail et quitterez l'université?

2. Tests de bout en bout

Si le logiciel devient de plus en plus complexe et que plusieurs personnes y travaillent, des tests sont obligatoires. Mais comme amon déjà mentionné, en ajoutant des tests unitaires à des logiciels scientifiques est assez difficile. Vous devez donc utiliser une approche différente.

Comme votre logiciel obtient son entrée à partir d'un fichier, comme la plupart des logiciels scientifiques, il est parfait pour créer plusieurs exemples de fichiers d'entrée et de sortie. Vous devez exécuter ces tests automatiquement sur chaque version et comparer les résultats avec vos échantillons. Cela pourrait être un très bon remplacement pour les tests unitaires. Vous obtenez également des tests d'intégration de cette façon.

Bien sûr, pour obtenir des résultats reproductibles, vous devez utiliser la même graine pour votre générateur de nombres aléatoires, comme l'a déjà écrit amon .

Les exemples doivent couvrir les résultats typiques de votre logiciel. Cela devrait également inclure les cas limites de votre espace de paramètres et des algorithmes numériques.

Vous devriez essayer de trouver des exemples qui ne nécessitent pas trop de temps pour s'exécuter, mais qui couvrent toujours les cas de test typiques.

3. Intégration continue

Étant donné que l'exécution des exemples de test peut prendre un certain temps, je pense qu'une intégration continue n'est pas possible. Vous devrez probablement discuter des parties supplémentaires avec vos collègues. Par exemple, ils doivent correspondre aux méthodes numériques utilisées.

Je pense donc qu'il vaut mieux faire l'intégration d'une manière bien définie après avoir discuté du contexte théorique et des méthodes numériques, des tests minutieux, etc.

Je ne pense pas que ce soit une bonne idée d'avoir une sorte d'automatisme pour une intégration continue.

Au fait, utilisez-vous un système de contrôle de version?

4. Tester vos algorithmes numériques

Si vous comparez des résultats numériques, par exemple lors de la vérification de vos sorties de test, vous ne devez pas vérifier l'égalité des nombres flottants. Il peut toujours y avoir des erreurs d'arrondi. Vérifiez plutôt si la différence est inférieure à un seuil spécifique.

C'est également une bonne idée de comparer vos algorithmes avec différents algorithmes ou de formuler le problème scientifique d'une manière différente et de comparer les résultats. Si vous obtenez les mêmes résultats en utilisant deux méthodes indépendantes ou plus, c'est une bonne indication que votre théorie et votre implémentation sont correctes.

Vous pouvez effectuer ces tests dans votre code de test et utiliser l'algorithme le plus rapide pour votre code de production.

Mon conseil serait de choisir soigneusement la façon dont vous déployez vos efforts. Dans mon domaine (bioinformatique), les algorithmes de pointe évoluent si rapidement qu'il est préférable de dépenser de l'énergie pour la vérification des erreurs de votre code sur l'algorithme lui-même.

Cela dit, ce qui est apprécié, c'est:

• est-ce la meilleure méthode à l'époque, en terme d'algorithme?
• la facilité de portage vers différentes plates-formes de calcul (différents environnements HPC, versions de système d'exploitation, etc.)
• robustesse - fonctionne-t-il sur MON jeu de données?

Votre instinct pour construire une base de code à l'épreuve des balles est noble, mais il convient de se rappeler que ce n'est pas un produit commercial. Rendez-le aussi portable que possible, à l'épreuve des erreurs (pour votre type d'utilisateur), pratique pour que d'autres contribuent, puis concentrez-vous sur l'algorithme lui-même