Mettre en place les bonnes pratiques de test #14

New Issue

florian_briand · 2024-07-06T19:54:31+02:00

florian_briand commented

2024-07-06 19:54:31 +02:00

Identifier les bonnes pratiques
Mettre en place les bonnes pratiques de tests unitaires
Définir si on met en place des tests fonctionnels haut niveau (tests de l'interface)
- Le cas échéant : créer une carte pour mettre en place la techno de tests fonctionnels

Bonnes pratiques théoriques

Documentation source :

The book :
- How to write tests
- Test organization
Organisation des fichiers de tests :
- On peut mettre les tests unitaires dans les mêmes fichiers que le code source, pour tester les fonctions privées. Pour cela, on encapsule les tests dans un module de tests :
```
#[cfg(test)]
mod tests {
  ...
}
```
- On peut mettre les tests d'intégration dans un dossier /tests à côté du dossier /src ; dans ce cas, pas besoin d'encapsuler dans un module de tests ; mais on ne peut tester que les fonctions publiques de la librairie

Doctests :

On peut également rajouter du code d'exemple dans la documentation des fonctions. L'ajout d'une documentation se fait à l'aide de commentaires commençant par ///.

/// Returns a range of characters from 'a' to 'z'.
///
/// # Examples
/// ```
/// use hello_rust::get_alphabet;
///
/// let alphabet = get_alphabet();
/// assert_eq!(alphabet, 'a'..='z');
/// ```
pub fn get_alphabet() -> RangeInclusive<char> {
    'a'..='z'
}

Bonnes pratiques P4pillon

?

- [ ] Identifier les bonnes pratiques - [ ] Mettre en place les bonnes pratiques de tests unitaires - [ ] Définir si on met en place des tests fonctionnels haut niveau (tests de l'interface) - [ ] Le cas échéant : créer une carte pour mettre en place la techno de tests fonctionnels # Bonnes pratiques théoriques Documentation source : - The book : - [How to write tests](https://doc.rust-lang.org/book/ch11-01-writing-tests.html) - [Test organization](https://doc.rust-lang.org/book/ch11-03-test-organization.html) - Organisation des fichiers de tests : - On peut mettre les tests unitaires dans les mêmes fichiers que le code source, pour tester les fonctions privées. Pour cela, on encapsule les tests dans un module de tests : ``` #[cfg(test)] mod tests { ... } ``` - On peut mettre les tests d'intégration dans un dossier `/tests` à côté du dossier `/src` ; dans ce cas, pas besoin d'encapsuler dans un module de tests ; mais on ne peut tester que les fonctions publiques de la librairie - Doctests : - On peut également rajouter du code d'exemple dans la documentation des fonctions. L'ajout d'une documentation se fait à l'aide de commentaires commençant par `///`. ``` /// Returns a range of characters from 'a' to 'z'. /// /// # Examples /// ``` /// use hello_rust::get_alphabet; /// /// let alphabet = get_alphabet(); /// assert_eq!(alphabet, 'a'..='z'); /// ``` pub fn get_alphabet() -> RangeInclusive<char> { 'a'..='z' } ``` # Bonnes pratiques P4pillon - ?

florian_briand added the

module/sesam-vitale

module/desktop

module/frontend

labels 2024-07-06 19:54:31 +02:00

florian_briand added this to the 0 - POC project 2024-07-06 19:54:31 +02:00

florian_briand added this to the 0 - POC milestone 2024-07-26 21:55:10 +02:00

florian_briand added the

independant

open-source

labels 2024-10-04 14:19:25 +02:00

florian_briand commented