Test-Driven Development

TDD
Le TDD est une méthode de développement logiciel qui consiste à développer les
tests avant de développer le code. Le TDD fonctionne comme suit :
On écrit un test qui décrit une fonctionnalité du programme
On exécute le test, qui doit échoué parce que la fonctionnalité n’a pas été
développée
Un écrire un code simple pour faire réussir le test
Re-écrire (refactor) le code pour qu’il répond au critères de simplicité
Répéter le processus pour les autres fonctionnalités
Critères de simplicité
Un ensemble de critères, par ordre de priorité, proposés par Kent Beck pour
évaluer si un code source est "assez simple":

le code est vérifié par des tests automatisés (tous les tests doivent réussir)

le code ne contient aucune duplication

le code exprime séparément chaque idée ou responsabilité distincte

le code est composé du nombre minimum de composants (classes,

méthodes, lignes) compatibles avec les trois premiers critères
Avantages du TDD
Réduction des défauts

Meilleure qualité du code

Pièges courants
Les erreurs individuelles typiques incluent :

oublier d'exécuter les tests fréquemment

écrire trop de tests à la fois

rédiger des tests trop large or trop petit

écrire des tests trop triviaux

écrire des tests pour du code trivial

Example
FizzBuzz

Un programme retourne Fizz si un nombre est divisible par 3, Buzz s’il est divisible
par 5, et FizzBuzz s’il est divisible par les deux. Le programme retourne le même
nombre s’il n’est divisible ni par 3 ni par 5
Références
Agile Alliance: https://www.agilealliance.org

Beck, Kent. Test-driven development: by example. Addison-Wesley Professional,

2003.
Mocks
Mocking
Mock objects are used to replace real software dependencies by simulating their
relevant features. Typically, methods of mock objects are designed to return some
desired values given specific input values.

Developers tend to mock dependencies that make testing difficult, i.e., classes
that are hard to set up, too slow or that depend on external resources
Source : Spadini, Davide, et al. "To mock or not to mock? An empirical study on mocking practices. (2017)
Example - Normal test
Example - test with patch
Example - test with Mock
Example - test with Mock/side_effect
Patch vs Mock
patch is preferred over Mock() because it ensures that the patch is reverted after
the test so there are no side effects on other tests or other code.
Exercice : Password-Strength-Checker
Use TDD to write a password strength checker that only accepts a password if it

- Password should have at least one uppercase character

- Password should have at least one lowercase character
- Password should have at least one digit
- Password should have at least one special character
- Password should be at least 12 characters long
- Password should not have any whitespaces
Hint: This is the complete list of ASCII Special Characters – !”#$%&'()*+,-.\:;<=>?@[/]^_`{|}~
and this can be represented by the following regular expression [^a-zA-Z0-9]