Partage d'aujourd'hui : Code propre – tests unitaires

Du point de vue du développement, organisez d'abord les variables et les fonctions selon certains noms et formats. Ensuite, commencez à écrire du code. Dans l'industrie, beaucoup préconisent le développement piloté par les tests.

TDD est l'abréviation anglaise de Test-Driven Development. Il s'agit d'une pratique et d'une technologie de base dans le développement agile et une méthodologie de conception. Le principe de TDD est d’écrire le code du cas de test unitaire avant de développer le code fonctionnel.

1. Trois lois du TDD

Loi 1 N'écrivez pas de code de production avant d'écrire des tests unitaires qui ne peuvent pas réussir.

Loi 2 : Vous ne pouvez écrire que des tests unitaires qui échouent tout simplement. L'échec de la compilation ne compte pas comme un échec.

Loi 3 : n'écrivez que le code de production qui est juste suffisant pour réussir le test qui échoue actuellement.

Les tests sont écrits avec le code de production, les tests sont juste écrits quelques secondes avant le code de production.

2. Gardez le test propre

Le code de test est aussi important que le code de production et doit être suffisamment rangé.

Tout ce qui est bon vient avec des tests.

Un code de test unitaire propre apportera de nombreux avantages à votre code. Plus les tests sont sales, plus le code finira par le devenir. Si des tests manquent, le code commence à pourrir.

3. Les tests propres

Les tests propres ont un élément très important : la lisibilité.

Le code de test doit être suffisamment clair, propre et expressif. Lors du test, dites beaucoup de choses en aussi peu de mots que possible.

Mode test : construction-exploitation-inspection,

La première étape consiste à construire les données de test

La deuxième étape consiste à exploiter les données de test

La troisième étape consiste à vérifier l'opération si les résultats attendus sont obtenus.

3.1 Test du langage pour des champs spécifiques

Utilisez les tests du langage de test pour le rendre plus lisible.

3.2 Double standard

Le code de l'API de test a des normes d'ingénierie différentes de celles du code de production. Il doit être simple, concis et expressif, mais il doit être aussi efficace que le code de production. .

4. Une assertion par test

Certaines personnes pensent que chaque fonction de test devrait avoir une et une seule instruction d'assertion.

Testez un concept chacun.

Une meilleure règle pourrait être de tester un seul concept et de faire une chose dans chaque fonction de test.

5. Principes F.I.R.S.T

Le code propre doit suivre les règles suivantes :

Les tests rapides doivent être suffisamment rapides. Les tests devraient s’exécuter rapidement.

Les tests indépendants doivent être indépendants les uns des autres. Un test ne doit pas définir les conditions du test suivant.

Les tests répétables doivent réussir à plusieurs reprises dans n'importe quel environnement.

Les tests d'auto-validation doivent avoir une sortie booléenne. Qu'il échoue ou réussisse, la conclusion doit être tirée directement, plutôt que de vérifier le journal pour confirmer si le test a réussi ou non.

Les tests opportuns doivent être rédigés en temps opportun. Les tests unitaires doivent être écrits juste avant le code de production qui les fait réussir.

6. Résumé

Les tests sont aussi importants que le code. Ils garantissent et améliorent l'évolutivité, la maintenabilité et la réutilisabilité du code de production. Gardez vos tests propres, expressifs et courts. Inventé comme API de test pour les langages spécifiques à un domaine pour vous aider à écrire vos propres tests.

Dans le développement réel, de nombreuses équipes n'ont pas de TDD ou de tests unitaires pour beaucoup de choses en raison de divers facteurs externes et internes, de calendriers de construction serrés, de délais courts, de tâches lourdes, etc. à ce principe et se rapproche lentement de l'objectif des tests unitaires...

Vous aimerez peut-être :

Or Trois Argent Quatre Saison de recherche d'emploi : Programmation Compétences et CV en entretien d'embauche

Comment devenir un excellent ingénieur full-stack en autodidacte ?