# Testing

## Pourquoi Tester ?

### Le coût du changement

Sans tests, le coût du changement augmente exponentiellement.

En l'absence de tests *(ou s'ils sont simplement insuffisants)*, il est **difficile d'évaluer si l'application fonctionne** comme attendu. Il devient **nécessaire de tester l'application manuellement à chaque changement** ; mais comment choisir les parties à tester et quels effets de bord attendre de chaque changement ?\
L'équipe finit par **éviter le changement pour éviter les régressions**.

### Cross-Browser et Cross-Platform

Les tests manuels peuvent s'avérer très rapidement couteux, particulièrement si l'on souhaite découvrir les anomalies spécifiques à certains browsers ou "devices" avant l'utilisateur final.

### Pas de tests, pas d'update

Une application Angular a généralement quelques **millions de lignes de code** en dépendance.\
**Chaque jour**, un peu moins d'**une dizaine** de ces dépendances sont mises à jour.\
**Comment profiter des mises à jour sans introduire de régressions** ?

### "Tests are Specs"

Les tests forment à la fois les spécifications et la documentation de l'application.

Pour découvrir *(ou mieux comprendre)* certaines fonctionnalités non documentées *(ou dont la documentation n'est pas à jour)* d'un module open-source *(e.g. Angular)*, les tests s'avèrent très intéressants comme source d'information.

Contrairement à des spécifications ou documentations, les tests ont l'avantage d'être toujours à jour.

## Les Familles de Tests

Nous aborderons ici les deux principales familles de tests Angular suivantes :

{% content-ref url="testing/unit-testing" %}
[unit-testing](https://guide-angular.wishtack.io/angular/testing/unit-testing)
{% endcontent-ref %}

{% content-ref url="testing/end-to-end" %}
[end-to-end](https://guide-angular.wishtack.io/angular/testing/end-to-end)
{% endcontent-ref %}