Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
C
cours_prog
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
yassin.elhakoun
cours_prog
Commits
3ab42429
Verified
Commit
3ab42429
authored
4 years ago
by
orestis.malaspin
Browse files
Options
Downloads
Patches
Plain Diff
added tdd
parent
40b1881b
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
slides/tdd.md
+135
-0
135 additions, 0 deletions
slides/tdd.md
with
135 additions
and
0 deletions
slides/tdd.md
0 → 100644
+
135
−
0
View file @
3ab42429
---
title
:
Test driven development (TDD)
date
:
2021-02-24
---
# Qu'est-ce que le TDD
## En deux phrases
*
Écrire les tests en premier;
*
Le code de l'application ensuite.
## Ou encore
*
Les spécifications de l'application sont transformées en tests;
*
Le code est amélioré pour passer les tests.
**D'habitude on fait l'inverse: on code et on écrit les tests après.**
# Cycle de développement
Une façon de voir le TDD est via la boucle suivante:
1.
Écrire un test qui échoue.
2.
Écrire juste assez de code pour que le test réussisse.
3.
Refactorer.
Et ainsi de suite jusqu'à ce que l'application soit écrite.
# Pourquoi utiliser le TDD
Il y a plusieurs avantages au TDD, notamment:
1.
Les tests sont complètement intégrés au cycle de développement:
*
plutôt qu'ajoutés (ou pas) à la fin,
*
les tests sont une garantie future.
2.
L'assurance que les tests testent les bonnes choses:
*
les fonctionalités au coeur de votre projet sont testées,
*
aide à la documentation.
3.
Toutes les fonctionalités sont couvertes:
*
chaque fonctionalité a son/ses tests avant d'être implémentée,
*
... "en théorie".
# Utilisation du TDD
## Quand utiliser le TDD
*
Quand votre projet est clairement défini (vous savez ce que vous voulez faire).
*
Savez assez clairement ce que sont les entrées/sorties.
*
Corrigez des bugs.
## Quand éviter le TDD
*
Quand vous expérimentez (language, algorithme, ...).
# Exemple
## Librarie de fractions
1.
Creation de fraction,
2.
Simplification d'une fraction,
3.
Addition de deux fraction,
...
# TDD: création de fraction
1.
Écrire un test:
```
C
frac a;
frac_init(&a, 4, 5);
assert(a.num == 4 && a.denom == 5);
```
2.
Écrire le code
```
C
typedef struct {
int num, denom;
}
void frac_init(frac *a, int num, int denom) {
a->num = num;
a->denom = denom;
}
```
# TDD: simplification de fraction (1/N)
1.
Écrire un test:
```
C
frac a;
frac_init(&a, -4, -5);
assert(a.num == 4 && a.denom == 5);
```
2.
Écrire le code
```
C
void simplify(frac *a) {
// write the code to simplify for two negative numbers
}
void frac_init(frac *a, int num, int denom) {
a->num = num;
a->denom = denom;
simplify(a)
}
```
# TDD: simplification de fraction (2/N)
1.
Écrire un test:
```
C
frac a;
frac_init(&a, 4, -5);
assert(a.num == -4 && a.denom == 5);
```
2.
Écrire le code
```
C
void simplify(frac *a) {
// refactor for one positive and one negative number
}
void frac_init(frac *a, int num, int denom) {
a->num = num;
a->denom = denom;
simplify(a)
}
```
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment