Est-il considéré comme une "mauvaise pratique" de vérifier le contenu / l'encodage du fichier dans les tests unitaires?


84

Un peu de contexte: un peu plus tôt dans la journée, j'ai dû mettre à jour le code SQL fourni par un autre de mes collègues. Comme il s'agit d'un script assez volumineux, il est stocké dans un fichier séparé (qui est ensuite lu et exécuté à l'exécution). Ce faisant, j'ai accidentellement réintroduit deux bogues remontant à quelques mois, à savoir:

  • Pour une raison quelconque, le fichier ASCII a été encodé en UTF-16 (le collègue m'a envoyé le fichier par courrier électronique, ce qui aurait pu le provoquer).
  • Le script manquait dans les SETinstructions initiales (requis en raison de certains éléments du pilote en production, mais pas lors d'une installation propre localement).

Après avoir débogué cela pendant environ une heure (encore), j'ai décidé d'écrire des tests unitaires pour s'assurer que cela ne se reproduirait plus jamais (et d'inclure un moyen rapide de le corriger dans le message d'assertion afin de fournir une solution simple aux futurs développeurs).

Cependant, lorsque j'ai appliqué ce code, un autre collègue (qui est également notre chef d'équipe) s'est approché de moi et m'a dit que je ne devrais plus refaire ces choses parce que:

"Ces choses ne font pas partie des tests unitaires"

"Les tests unitaires ne doivent être utilisés que pour vérifier le flux de votre code"

Je suis assez en conflit maintenant car je pense toujours que ce que je fais n'est pas faux, car ce bogue ne serait pas réintroduit à l'avenir. Cependant, ce collègue travaille en tant que senior et décide en fin de compte de ce que nous passons notre temps dessus. Que devrais-je faire? Ai-je tort de le faire de cette façon? Est-ce considéré comme une mauvaise pratique?



35
" Les tests unitaires ne doivent être utilisés que pour vérifier le flux de votre code " Je dirais que ce sont des conneries. Traditionnellement, ils devraient inclure tous les tests nécessaires pour s'assurer que "l'unité" considérée isolément est correcte. Si vous écrivez uniquement les tests unitaires qui sont utiles pour "vérifier le flux", peu importe ce que cela signifie, j'espère que vous disposerez également de suites de tests approfondies séparées (écrites par le service d'assurance qualité?).
gbr

8
De toute façon, le problème de votre collègue se situe probablement au même endroit où vous mettez ces tests. Je me concentrerais là-dessus, en laissant de côté les discussions sur les confessions et les guerres saintes. Il est possible que ces tests soient trop lents pour la suite à laquelle vous les avez ajoutés, mais il est également tout à fait possible que votre collègue soit simplement obsédé par son idée des tests unitaires et crée un problème à partir d'un problème inexistant; il est donc préférable de commencer par clarifier le vrai problème.
gbr

2
En passant, ces tests ressemblent à quelque chose que vous voudriez exécuter à chaque fois que vous modifiez ce fichier SQL. Ici, le principal problème pourrait être lié aux outils de test, qui pourraient ne pas prendre en charge un mode de fonctionnement "exécuté uniquement si modifié"; Si cela pose des problèmes réels et concrets, il peut être intéressant d’inclure manuellement la fonctionnalité "uniquement si modifiée" avec quelques kludges uniquement pour ces tests spécifiques.
gbr

5
Au lieu de vérifier que le fichier a le contenu et l'encodage correct, pourquoi ne pas vérifier qu'il fonctionne ?
user253751

Réponses:


156

Très probablement, les tests que vous avez écrits sont plus proches des tests d'intégration ou de régression que des tests unitaires. Bien que la ligne puisse être très floue et qu’il y ait parfois de la confusion dans le pédantisme pour ce qui est ou non un test unitaire, je reviens vers votre collègue pour vous demander où devraient être les tests que vous avez écrits, car ils apportent une valeur ajoutée en garantissant l’exactitude du code.

Je ne me concentrerais pas trop sur ce qui est ou n’est pas un test unitaire et réaliserais que même si c’est un test d’intégration, le test pourrait toujours avoir de la valeur.


Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
Thomas Owens

36

Techniquement, ce n'est pas un test unitaire, mais plutôt une étape de validation. La bonne approche dépend vraiment de ce que votre flux de travail doit être. Le chef d’équipe a raison sur l’utilité des tests unitaires. Mon sentiment est qu'il s'agit d'utiliser le mauvais outil pour un travail qui reste à faire. Alors commencez par ceci:

Quel est le problème que j'essaie de résoudre?

Selon la description, vous devez vérifier que tous les scripts de base de données sont conformes à certaines normes.

Quels outils / processus sont disponibles pour résoudre le problème?

La qualité du code source est généralement contrôlée par des outils d' analyse statiques . Si vous ne disposez pas d'un outil d'analyse statique pour valider votre code SQL, vous pouvez créer un outil rapide et sale qui effectue la vérification de tout fichier SQL qui lui est transmis. Il n’est pas inutile de vérifier s’il existe des outils d’analyse statique capables de traiter les problèmes dont vous parlez.

Si vous intégrez cette partie de votre infrastructure de génération, par exemple en l’intégrant à Jenkins, vous pouvez l’appliquer à tous les fichiers SQL de votre projet.

Les tests unitaires ne résolvent que le problème de votre fichier actuel.

Comment puis-je communiquer le besoin de l'outil?

C'est assez facile, vous parlez à votre chef d'équipe. Il peut travailler avec le propriétaire du produit et avec vous pour déterminer le risque / avantage d’investir dans l’outillage. S'il s'agit probablement d'un problème ponctuel, l'outillage sera probablement excessif. Si l’outillage permettant d’attraper les plus gros problèmes est facile, cela vaut peut-être la peine, rien que pour le contrôle de cohérence.

Votre chef d'équipe peut avoir des idées que vous (ou moi) n'avons pas prises en compte, qui peuvent résoudre le problème plus correctement.


21
Lorsqu’on discute du coût par rapport au risque, il est important de noter qu’il a déjà causé une perte de temps en raison de la réintroduction de bogues précédemment résolus. Cela seul est un argument fort pour automatiser la vérification. +1
jpmc26

1
@ jpmc26, je suis complètement d'accord. La discussion devrait commencer par le fait que vous avez perdu beaucoup d'heures à comprendre ce qui n'allait pas et que les tests de votre unité constituaient votre première tentative d'empêcher le reste de l'équipe de perdre le même temps. Cependant, travailler avec le chef d’équipe qui doit répondre à la direction et aux parties prenantes est généralement très apprécié. En tant que chef d’équipe, je veux pouvoir défendre les outils / pratiques / codes que nous gérons. Si je voyais des tests unitaires impossibles à retracer aux exigences réelles, je serais également concerné.
Berin Loritsch

1
@BerinLoritsch Techniquement, ce n'est pas un test unitaire, j'aimerais vraiment savoir sur quelle "technique" vous basez cette assertion. Autant que je sache, il n’existe pas de définition unique des tests unitaires faisant autorité, et chacun en est venu à se faire sa propre idée de ce qu’ils " sont ".
gbr

2
@gbr Il existe un accord informel entre les développeurs selon lequel les tests unitaires sont des tests exécutés indépendamment des systèmes externes. Ils testent uniquement le code lui-même, pas les interactions avec les fichiers, les bases de données ou d'autres services externes. Wikipedia documente cette compréhension: en.wikipedia.org/wiki/Unit_testing#External_work .
jpmc26

1
@BerinLoritsch Il est également possible que nous interprétions tous la question différemment. De toute façon, la question n'était pas très détaillée et l'auteur n'a encore été communiqué à personne. De toute façon, je ne suis pas très intéressé à discuter plus avant de la classification de ces tests. Ce qui est important, c’est de savoir s’ils devraient exister (je suis presque sûr qu’ils le devraient) et à quelle fréquence les faire tourner (à chaque changement dans l’EDI, à chaque fois). local commit, à chaque accès au référentiel central, à tout moment ...).
gbr

19

Il est déconseillé d’appeler des tests qui accèdent aux fichiers "Tests unitaires".

Il: "Ces choses ne font pas partie des tests unitaires"

Vous: "Cela a du sens, mais je ne pourrais pas trouver un meilleur endroit pour les mettre. Où sont-ils?"

Malheureusement, les types de tests existants et leur organisation sont entièrement spécifiques à l'entreprise. Vous devrez donc savoir comment votre entreprise gère ces tests.

Si vous ne disposez pas encore d'un moyen d'exécuter des tests automatisés autres que les tests unitaires, l'approche pragmatique consiste à marquer les tests unitaires qui ne sont pas réellement des tests unitaires avec un préfixe, jusqu'à ce que vous en ayez assez pour commencer à déterminer quel type de test. tests que vous avez réellement / besoin. Après cela, vous pouvez commencer à vous organiser.


2
Il est déconseillé d’appeler des tests qui accèdent aux fichiers "Tests unitaires". Ici, le fichier auquel on accède est le fichier source . Il sera accessible autant que n’importe quel fichier source (pour l’analyser). Le fait que le test ne soit probablement pas rédigé dans le même langage que l '"unité" contrôlée (SQL) le rend peu orthodoxe mais ne doit pas influencer sa classification en tant que test unitaire. continue ...
gbr

1
... En fait, le codage correct d'un fichier est un "test" qui est effectué par un compilateur chaque fois qu'il lit un fichier source. Ici, le problème est qu’étant un fichier externe interprété au moment de l’exécution, les "tests du compilateur" ne seront pas exécutés automatiquement. Il est donc tout à fait approprié de les ajouter explicitement, et je pense que cela peut être considéré à juste titre comme un "test unitaire" de ce dernier. Extrait de code SQL. Et il semble raisonnable de l'inclure dans la suite (potentielle) de tests exécutés à chaque modification du fichier.
gbr

3
Par ailleurs, il est généralement recommandé d’accéder aux fichiers externes lorsque cela peut être remplacé par un simulacre ou quelque chose du même genre. Et selon la plupart des définitions, les tests unitaires peuvent accéder à des fichiers externes ou autres, il est simplement fortement déconseillé, car cela peut ralentir considérablement les choses. Une boutique est libre de prescrire que vous ne pouvez pas ajouter de tests accédant aux fichiers à la suite de tests la plus fréquemment exécutée, mais cela ne rend pas ces tests indignes de la désignation "unité de test", ils les font juste "non à intégrer à la suite de tests de ce projet ".
gbr

2
@Warbo Il est une mauvaise pratique pour accéder aux fichiers (en général), et ( le plus important) la raison est qu'ils ne tardent pas si elles impliquent « GBS Relisez un lien NFS squameuse », ils sont lents si, par exemple , citant Michael Feathers , ils prennent 1 / 10ème de seconde. C'est parce que vous voulez exécuter vos tests aussi souvent que possible, idéalement à chaque changement apporté dans l'EDI, et lorsque vous en avez beaucoup (comme il se doit), même des dixièmes de secondes cumulent des heures. (continue ...)
gbr

1
@Warbo .. Cela dit, ce qui compte, c'est le temps total qu'ils prennent. Par conséquent, si vous avez un très petit projet qui, vous en êtes sûr, restera petit, vous pouvez être beaucoup plus indulgent quant à la rapidité des tests individuels. Et si vous ne souhaitez vraiment pas les utiliser fréquemment, vous êtes tout à fait libre de les laisser appeler un employé de l'OPMROC pour qu'il récupère et envoie par télécopie un fichier d'un classeur. Vous pouvez également choisir d’être plus laxiste pendant que vous avez encore peu de tests et revenir en arrière pour les accélérer quand ils commencent à en prendre trop, mais vous devez prendre en compte le fait que c’est une dette que vous accumulez.
gbr

14

Michael Feathers dit ceci dans son livre Travailler efficacement avec Legacy Code:

Dans l'industrie, les gens se demandent souvent si des tests particuliers sont des tests unitaires. [...] Je reviens aux deux qualités: le test est-il rapide? Peut-il nous aider à localiser rapidement les erreurs?

Votre test aidera-t-il à localiser rapidement les erreurs et à les exécuter rapidement? Si oui, alors fais-le! Si non, alors ne le faites pas! C'est aussi simple que ça!

Cela étant dit, vous travaillez dans un environnement avec d’autres personnes et devez vous entendre avec elles. Vous devrez peut-être le faire à sa manière, même si vous n'êtes pas d'accord avec cela en privé.


C'est une bonne règle, mais il aurait épargné la confusion s'il avait écrit " s'il fallait ajouter des tests particuliers à la suite de tests la plus fréquemment exécutée ", plutôt que de jouer avec le terme "test unitaire".
gbr

1
@gbr Si les résultats du test sont exacts, la seule chose qui compte est la rapidité de l'exécution. Si j'ai 100 tests qui fonctionnent chacun en moins de 0,1 s, ils dureront au total moins de 10 s. Je suis heureux de les exécuter fréquemment. Si j'ai 1000 tests, ils prendront jusqu'à 1m40s. C'est trop long, je ne les lancerai pas souvent, mais je les exécuterai une fois les modifications apportées avec le petit groupe de 100 tests. Peu m'importe si c'est techniquement un test d'acceptation ou autre chose. Si cela m'aide à trouver les erreurs plus tôt, je le ferai indépendamment de la sémantique. Un test ne fournit de la valeur que lorsqu'il est exécuté.
CJ Dennis

Je suis plutôt d'accord (l'indépendance est une autre chose très importante, par exemple), mais néanmoins, il aurait été préférable que Michael Feathers n'ait pas aggravé la confusion sur ce que signifie "test unitaire". Ce n’est pas qu’il soit particulièrement responsable de cette confusion (et son livre est excellent, dans les passages que j’ai parcourus jusqu’à présent). Je faisais un point plutôt mineur, de toute façon.
gbr

@gbr Il ne redéfinit pas les tests unitaires, il dit que cela ne devrait pas être votre critère d'inclusion. Votre critère devrait être l’utilité, et c’est ce qu’il définit.
CJ Dennis

Je relis cette section; Je ne suis pas sûr, il m'est difficile de savoir si c'est censé être une définition ou un critère. Mais en réalité " Peut-il nous aider à localiser rapidement les erreurs " pourrait très bien impliquer les choses qu'il a déjà dites, à propos de l'isolement, etc. J'aurais donc peut-être fait du bruit pour rien (bien que votre réponse seule puisse encore être mal interprétée)
gbr

10

J'ai parfois écrit des tests similaires sur des fichiers de code source, des fichiers de configuration, etc. Je ne les appellerais pas des tests unitaires car (a) ils accèdent au système de fichiers et peuvent ne pas être ultra-rapides (b) Peu m'importe qu'ils soient exécutés à chaque enregistrement (par Serveur CI).

Vous pourriez les appeler des tests d'intégration; ils sont certainement plus proches de cette perspective que les tests unitaires.

Mon propre terme pour eux est des tests de ressources . À mon humble avis, ils sont entièrement justifiés s’ils sont exécutés de nuit sur un serveur CI: les coûts sont minimes et, s’ils sont utilisés judicieusement, ils apportent clairement une valeur ajoutée. Une définition de judicieusement : si le test vérifie un problème qui a provoqué un problème (tel que le codage que vous avez mentionné).


4

Un test unitaire consiste à tester une méthode ou une «unité» de code. Vous testez le plus petit groupe de logique et de code dans votre logiciel.

Plus tard, lorsque vous rejoindrez cette unité avec d’autres unités, vous effectuerez des tests d’intégration.

J'espère que votre chef d'équipe a encouragé votre initiative et aurait dû proposer d'autres suggestions. Vous avez certainement la bonne idée.

Votre code SQL est un code comme n'importe quel langage de génération inférieure tel que C # ou Java et doit être testé en tant que tel. Et la vérification et la validation appartiennent à tous les niveaux de test. Donc, les instructions d'encodage et SET sont incluses, mais ne sont pas nécessairement testées exclusivement. Des éléments généraux tels que les fins de ligne ou les entourages, vous pouvez généralement simplement utiliser un hook ou une fonctionnalité SCM.

La meilleure pratique consiste à avoir des tests de régression pour s'assurer que les anciens bugs ne sont pas réintroduits. Généralement, les tests sont créés parallèlement à toute résolution du bogue. Si ces bogues ne sont pas couverts par les tests de régression au niveau unité / intégration ou système, puis réintroduits, il s'agit d'un problème d'équipe, d'un problème de processus et non d'un problème individuel.

Le problème est que ... les erreurs de syntaxe, les instructions manquantes ou les blocs logiques au sein d'une "unité" ne sont généralement pas testés. Vous testez les entrées et les sorties de l'unité selon différentes combinaisons, en testant les nombreuses possibilités pouvant être générées.

Pour en revenir aux instructions SET manquantes, elles aident à informer les nombreuses possibilités d’entrée et de sortie à tester. Quel test écririez-vous qui échouerait s'il vous manquait un SET choisi?


Le test "unité de code" est une approche du test unitaire. D'après mon expérience, cela conduit à des tests fragiles et à un gonflement massif (par exemple une moquerie excessive). Une approche alternative, et à mon humble avis, meilleure approche des tests unitaires est "unité de fonctionnalité". Peu importe que certaines fonctionnalités (par exemple, "définir un cookie une fois connecté") nécessitent une méthode ou une douzaine de processus intercommunicants, cela ne représente qu'une unité.
Warbo

@Warbo - J'appellerais cela plus proche (mais pas) des tests d'intégration. Les tests unitaires n'exigent rien excessif ou massif. Les tests unitaires doivent être petits et rapides. En fait, les tests par fonctionnalité mènent à ce que vous décrivez. Les tests fragiles sont 1. ceux qui sont plus grands ou qui font plus que ce qu’ils devraient. 2. fortement couplé 3. ne pas avoir une seule responsabilité.
Ross

3

Si des fichiers font partie de votre produit, leur contenu doit être correct. Aucune raison pour laquelle vous ne voudriez pas vérifier cela. Par exemple, si vous avez besoin de six images 1024x 1024 dans un dossier, alors écrivez un test unitaire qui vérifie que vous avez bien cela.

Mais vous n'avez probablement pas que les fichiers, vous avez aussi du code qui lit les fichiers. Vous pouvez écrire un test unitaire pour ce code. Dans l'exemple ci-dessus, la fonction de lecture de l'une des six images renvoie-t-elle une image de 1024 x 1024 en mémoire (ou quoi que cela soit supposé produire).

Quoi qu’il en soit, il ne s’agit peut-être pas d’un test unitaire, mais c’est un test utile. Et si vous utilisez un framework de test unitaire qui vous permet de faire un test utile (ce n’est pas un test unitaire), pourquoi ne pas utiliser le framework de test unitaire?


2

Je comprends peut-être mal votre problème, mais pour moi, cela ressemble à un problème qui ne devrait pas nécessairement être capturé par un test spécifique, mais simplement par le système de contrôle de version . Toute modification apportée à une base de code doit être examinée patch par patch avant d'être validée. Un moyen simple de faire cela dans git est d’ajouter les modifications avec

git add -p

Pour chaque modification dans un fichier texte, le répertoire de travail vous demandera si vous souhaitez réellement le conserver. Cela vous permettrait de voir, par exemple, la suppression de ces « SETdéclarations initiales ».

Si le codage de tout un fichier était modifié, quelque chose de différent se produirait cependant: l'algorithme ne parviendrait pas à différencier l'ancien et le nouveau fichier et, par conséquent git add -p, n'ajouterait rien. Ce serait alors visible dans l'autre commande que je ferais avant tout commit, à savoir

git status

Ici , vous verriez le fichier en rouge, ce qui indique qu'il ya des changements. Enquêter sur les raisons pour lesquelles ils ne l’ont pas fait git add -prendrait rapidement le problème évident.


dites, comment cela aide-t-il les futurs développeurs à éviter exactement le même problème? ... ce qui concerne les tests automatisés (également les assertions et la conception par contrat), c’est qu’ils sont, en fait, automatisés .
Vaxquis

@vaxquis évite exactement le même problème - bien que ce soit un peu par coïncidence, en tant qu'effet secondaire d'un flux de travail, c'est une bonne idée pour différentes raisons. Mon problème est que ce problème pourrait se produire à tout moment, ce qui montre que l'équipe du PO n'a pas très bien utilisé son VCS. - Rien contre les tests automatisés, mais leur valeur est de tester des propriétés sémantiques qui pourraient rompre avec des modifications inoffensives de la logique du programme. Il ne s'agit pas de vérifier toutes les possibilités stupides de modification du code source .
gauche vers

par votre logique, nous n'avons pas besoin de ceintures de sécurité; nous avons juste besoin de conduire plus prudemment et de causer moins d'accidents ... Vous avez manqué le point principal soulevé par OP - celui d' une erreur humaine . Aucune quantité de VCS ne peut vous protéger de cela . Aussi, FWIW: si un test peut être automatisé, il devrait l'être. Les humains sont toujours les maillons les plus faibles des processus d'ingénierie. gitest le meilleur exemple de cela - un excellent outil, mais à peine inutilisable pour les simples mortels .
vaxquis

@vaxquis Non, non! Les ceintures de sécurité sont analogues aux types d'essais qui ont du sens: elles détectent un large éventail de situations susceptibles de se produire par accident. Un test de codage de fichier serait analogue à un robot qui vous suivra et vous empêchera de vous asphyxier en vous fourrant des haricots dans le nez.
leftaroundabout

Selon l'OP, les fichiers du format incorrect ont passé deux fois déjà, apparemment ils sont susceptibles de se produire par accident.
gnasher729

1

Un autre angle à considérer: étant donné que ces deux conditions sont des conditions indispensables à l’exécution de votre programme, ne devriez-vous pas intégrer la logique près de la logique d’exécution? Je veux dire: vous testez l’existence d’un fichier avant de le lire et / ou vous validez son contenu, non? Alors, en quoi est-ce différent? Je pense que puisqu'il s'agit d'une ressource externe au code, elle devrait être validée au moment de l'exécution, avant qu'elle ne soit réellement utilisée. Résultat: application plus puissante, pas besoin d'écrire des tests supplémentaires.


1
Comment le fait d’échouer uniquement au moment de l’exécution en fait-il une application plus forte? Bien sûr, il peut également être approprié d’avoir des contrôles d’exécution proches de la source du problème, mais si vous pouvez détecter les erreurs avant qu’elles ne causent des problèmes d’exécution, c’est bien mieux, vous ne pensez pas? Êtes-vous sûr de connaître les tests automatiques?
gbr

1
"Comment ne pas échouer seulement au moment de l'exécution rendent l'application plus forte?" Lance une exception si la vérification échoue. Dans votre test, vérifiez que la section de code en cours de test renvoie le résultat attendu: cela supprime la charge de vérifier une raison supplémentaire pour l'échec.
Dr. Gianluigi Zane Zanettini

1
Votre stratégie n'a (presque) rien à voir avec les tests unitaires et les tests automatisés en général, c'est une chose différente, avec des utilisations différentes.
gbr

1
J'allais suggérer ceci. Le bogue est un détail d'implémentation; J'imagine que les réponses seraient très différentes si le codage douteux était dans un champ privé plutôt que dans un fichier autonome! Il semble que OP ait 2 problèmes: les fichiers de ressources peuvent être mal encodés et la production se comporte différemment de dev. En vérifiant le fichier au moment de l'exécution, juste avant son utilisation, nous résolvons le deuxième problème: dev et prod génèrent la même erreur. Les tests unitaires peuvent ensuite se concentrer sur la fonctionnalité réelle plutôt que sur les détails de la mise en œuvre; ces contrôles "internes" seront exercés comme des méthodes privées.
Warbo

1
@ Dr.GianluigiZaneZanettini Bah ... J'abandonne ... Comme je le vois, au mieux votre réponse, après vos "éclaircissements" dans les commentaires, était hors sujet (pas une réponse à la question), mais en réalité, en l'état, c'est tout simplement faux! pas besoin d'écrire des tests supplémentaires ??? Je n'ai pas assez de réputation pour réduire le vote, mais considérez comme si je l'avais fait. Et je ne pense pas qu'il soit très utile de poursuivre cette conversation.
gbr

1

Les tests ont le même code que tous les autres et, s'ils sont suffisamment complexes, bénéficient également de ... tests unitaires. Il semble plus simple d'ajouter de tels contrôles préalables directement dans le test.

La plupart des tests sont assez simples pour ne pas l'exiger, mais si certains sont suffisamment complexes, je ne vois rien de fondamentalement faux avec ces vérifications de précondition. Bien sûr, le test devrait également échouer sans eux, mais un bon test d'unité indique également quelle unité est en train d'échouer.

Un script utilisé dans le cadre du test et qui doit avoir un certain contenu et le codage est probablement une unité. Il peut avoir beaucoup plus de code et de logique que le reste du test. Un test avec un tel script n'est pas la meilleure conception de tous les temps et, si possible, devrait être reformulé en quelque chose de plus direct (sauf s'il s'agit d'un test d'intégration).


1
l'auteur ne dit nulle part que ce script SQL fait partie de certains tests, vous semblez avoir mal interprété la question
gbr

Difficile à comprendre, je suppose que le script SQL fait partie du test.
h22

votre commentaire "Il est difficile de comprendre" ...
gbr

Difficile à comprendre. Downvoting la question.
h22

1

Premièrement, l'un des objectifs des tests est d'empêcher que des problèmes ne se reproduisent dans votre code. Vous devez donc absolument continuer à écrire des tests de cette nature.

Deuxièmement, il est difficile de nommer. Oui, ce ne sont clairement pas des "tests unitaires", mais ils peuvent être des éléments souhaitables et nécessaires du processus de construction, car ils vous protègent contre les erreurs évidentes, et parce qu'ils vous informent plus tôt des erreurs conséquences sur une boîte de dev).

La question est donc (devrait être dans votre contexte) plus de savoir quand et comment ces tests sont exécutés que ce qu’ils sont.

J'ai utilisé ce type de test de manière intensive par le passé - ils nous ont évité une bonne partie de la douleur.


Et si quelqu'un voulait bien expliquer la motion, je l'apprécierais
Murph

1

Les tests unitaires consistent à exécuter une unité de code de manière isolée pour confirmer qu'elle produit le résultat correct pour l'entrée correcte. L’isolation doit permettre à l’unité testée et au test lui-même de se répéter, c’est-à-dire qu’ils ne doivent pas dépendre d’effets secondaires ni y être associés.

SQL n'est pas exactement quelque chose qui peut être testé isolément. Par conséquent, tout test de SQL n'est pas exactement un test unitaire et, à l'exception des instructions SELECT, il est presque certain qu'il aura un effet secondaire. Nous pouvons appeler cela un test d'intégration plutôt qu'un test unitaire.

Il est toujours sage de s'assurer que tout défaut qui pourrait être introduit peut être détecté le plus tôt possible dans le cycle de développement, et il est donc utile de le faire d'une manière qui facilite l'identification de la source du défaut afin qu'il puisse être rapidement détecté. corrigée.

Les tests en question peuvent être plus judicieusement délocalisés du corps des "tests unitaires" et placés ailleurs, mais ils ne doivent pas être totalement supprimés s'ils servent à quelque chose d'utile, comme se prémunir contre l'introduction éventuelle d'un défaut qui pourrait prendre des heures à suivre. vers le bas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.