Comment améliorer le test de votre propre code [fermé]

12

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement les réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 4 ans .

Aujourd'hui, j'ai vérifié un changement de code qui s'est avéré ne pas fonctionner du tout à cause de quelque chose de plutôt stupide mais très crucial. Je me sens vraiment mal et j'espère que j'en tirerai enfin quelque chose. Ce qui est stupide, c'est que j'ai déjà fait ces choses auparavant et je me dis toujours que la prochaine fois je ne serai pas aussi stupide ... Puis ça se reproduit et je me sens encore pire.

Je sais que vous devriez garder le menton levé et apprendre de vos erreurs, mais voici le problème: j'essaie de m'améliorer, je ne vois tout simplement pas comment empêcher ces choses de se produire.

Alors maintenant, je vous demande les gars: avez-vous certaines règles de base lors du test de votre code?

self-improvement testing

— Peter
source

1

Cela peut aider: programmers.stackexchange.com/questions/45479/…

— Amir Rezaei

17

Écrivez des tests avant de modifier le code.

Si la modification que vous proposez est de corriger un bogue, faites d'abord échouer le test en démontrant le bogue. Assurez-vous ensuite qu'il passe après avoir corrigé le bogue. Si vous écrivez le test par la suite et que vous ne l'avez vu que passer, vous ne pouvez pas être sûr qu'il a correctement testé le bogue en premier lieu.

Si la modification que vous proposez consiste à modifier une fonctionnalité existante ou à ajouter une fonctionnalité, écrivez des tests pour garantir une bonne couverture de la zone de code que vous allez modifier. Assurez-vous que ces tests réussissent avant de commencer à modifier le code et réussissent quand vous avez terminé.

— Alb
source

C'est vraiment un bon conseil, cela peut prendre un peu plus de temps pour obtenir un correctif, mais cela ne me fera certainement pas recommencer ce genre d'erreurs et cela me permettra d'écrire un code plus stable dans l'ensemble.

— Peter

@Peter devrait permettre de gagner du temps de maintenance à long terme. Vous devriez avoir besoin de passer moins de temps à corriger manuellement les correctifs de test et les tests seront également en place pour la prochaine fois que le code sera modifié. Parfois, vous pouvez même constater que l'écriture rapide d'un test unitaire qui reproduit le bogue peut accélérer le débogage et la correction du bogue en premier lieu.

— Alb

@Peter Je me retrouve souvent à reproduire le bogue plusieurs fois en le corrigeant. Écrire un petit test permet plutôt de gagner du temps, sans oublier que vous pouvez être absolument sûr que cela fonctionne (et fonctionnera à l'avenir).

— DasIch

c'est un excellent copain de conseil, merci beaucoup!

— Shaheer

@Alb ou même à court terme.

3

N'oubliez pas de tester les cas de bord! Beaucoup de bogues sont dus au fait que l'action la plus courante a été testée, mais pas les moins courantes.

— HLGEM
source

À mon humble avis, le véritable joyau est de trouver ces cas de bord. Je suis souvent surpris par les bugs qui sortent d'un système, simplement parce que nous n'avons pas pensé à un scénario particulier.

— Peter

2

Suivez les conseils techniques dans les réponses techniques; ce sont de bonnes choses. Ma réponse est plus sur l'attitude.

Se sentir mal de faire le genre d'erreur que chaque développeur commet de temps en temps est tout simplement absurde et ne vous aide pas à ne pas faire ce genre d'erreur à l'avenir. Pendant que vous êtes assis là à vous sentir mal, la construction est toujours cassée, vous savez? Et puis, votre travail consiste à éviter les erreurs, ce qui, je le sais, fait que sortir du lit le matin est une aventure passionnante tous les jours, non?

J'ai entendu parler d'entreprises où l'enregistrement de code cassé est une cause de honte publique. Je n'arrive même pas à comprendre ce genre de pensée déformée, frat-boy, junior-high-level qui conduirait à un tel comportement. Il ne peut guère y avoir rien de plus contre-productif pour un chef d'équipe ou un manager.

Alors ne vous battez pas. Nous l'avons tous fait. Je me suis probablement coûté une demi-journée par semaine en erreurs stupides, et je fais ça depuis (toux) depuis longtemps. Voilà à quoi cela ressemble d'écrire du code - vous vous battez constamment contre ce qui semble être vos propres insuffisances. Ce qui fait d'un professionnel un professionnel n'est pas une qualité mythique de ne jamais commettre d'erreurs (y compris parfois de grosses erreurs), mais la façon dont ils RÉPONDENT aux erreurs qu'ils commettent.

S'il y a un mantra que je pourrais inculquer à chaque développeur avec lequel je travaille, c'est celui-ci: vous n'êtes pas votre code . Vous écrivez du code. Vous l'écrivez aussi bien et efficacement que possible. Ensuite tu rentres chez toi. Si vous assimilez votre valeur ou votre estime de soi en tant que personne à la qualité de votre code, vous manquez simplement le bateau qui vous êtes vraiment.

— Dan Ray
source

Je comprends ce que vous dites à propos de la honte publique, mais en même temps, il est frustrant d'être bloqué car la version est interrompue parce que Joe Bloggs n'a pas construit toutes les plates-formes avant l'enregistrement.

— tenpn

@tenpn - Totalement. Mais le revers de ce que je dis est également vrai pour Joe Bloggs. Il n'est pas non plus son code. En tant que collègues, nous devons résister à l'impulsion de transformer Joe en idiot à nos yeux parce qu'il a commis une erreur que n'importe lequel d'entre nous aurait pu commettre.

— Dan Ray

@tenpn en fait, vous pouvez également reprocher au système de ne pas tester automatiquement la génération avant de valider les modifications sur le tronc / maître.

— David

2

@tenpn - Ni l'un ni l'autre ne bat vos collègues.

— Dan Ray

1

Et si le changement ne rompt pas la version? Il est logique de créer votre code avant de vous enregistrer. Il n'est pas si évident de tester votre code de toutes les manières possibles. Il y a toujours un scénario auquel vous ne pouviez pas penser. Aujourd'hui encore, je suis tombé sur une erreur d'arrondi à virgule flottante qui ne se produit que si vous avez les bons (mauvais) nombres

— Peter

2

Une autre pratique de test importante consiste à écrire le test et à vous assurer qu'il échoue au moins une fois AVANT d'écrire le code. Il est facile de gâcher et d'écrire un test de tautologie qui ne teste pas accidentellement la condition que vous recherchez. Les fausses assurances sont presque (et parfois pires) qu'aucune assurance.

— Uri
source

0

Une idée que j'ai utilisée de temps en temps est la suivante,

créez une branche et cassez votre code, exécutez le test et assurez-vous que le test détecte l'erreur.

— Zachary K
source

0

Avez-vous certaines règles de base lors du test de votre code?

Testez toujours votre code à l'unité et essayez d'atteindre une couverture aussi élevée que possible.

Quelques points généraux supplémentaires:

investir du temps dans la conception et la planification avant de commencer à coder
refactorisez votre code!

— BЈовић
source