# Diagnostic : tests et base de données

## Ce qui n’a pas changé

- **L’application** utilise toujours la base définie dans `.env` :
  - `DB_CONNECTION=mysql`
  - `DB_DATABASE=eventshbf` (ta base actuelle)
  - `DB_USERNAME=root`, `DB_PASSWORD=...`, etc.

Aucune modification de ce comportement : l’app tourne bien sur ta base existante.

## Pourquoi les tests parlent de la base `testing`

Quand tu lances **PHPUnit** (`php artisan test` ou `./vendor/bin/phpunit`), Laravel charge la config de **`phpunit.xml`** avant les tests.

Dans `phpunit.xml` on a notamment :

```xml
<env name="DB_DATABASE" value="testing"/>
```

Donc **pendant les tests uniquement** :

- `APP_ENV` devient `testing`
- `DB_DATABASE` est **écrasé** par `testing` (au lieu de lire `eventshbf` depuis `.env`)

Le reste (host, user, password, etc.) vient toujours de `.env`. Seul le **nom de la base** change pour la durée des tests.

C’est un choix volontaire de Laravel :  
les tests utilisent une base dédiée pour ne pas toucher à la base de développement (`eventshbf`). Les tests qui utilisent `RefreshDatabase` recréent les tables à chaque fois ; si on pointait vers `eventshbf`, tu perdrais les données de dev à chaque exécution des tests.

## Résumé

| Contexte              | Fichier de config   | Base utilisée   |
|-----------------------|---------------------|-----------------|
| Application (web, CLI)| `.env`              | `eventshbf`      |
| Tests PHPUnit         | `.env` + `phpunit.xml` | `testing` (imposé par phpunit.xml) |

Rien n’a “changé” côté app : c’est le **même mécanisme** qu’avant. La base `testing` n’a sans doute jamais existé sur ta machine ; les tests n’avaient peut‑être pas été lancés, ou l’étaient dans un autre environnement (CI, autre poste) où `testing` existait déjà.

## Que faire si tu veux lancer les tests avec MySQL

Tu as trois options :

1. **Créer la base `testing`** (recommandé pour garder le comportement actuel)  
   - Même serveur / même user que `eventshbf`, une base nommée `testing`.  
   - Les tests continuent à utiliser `DB_DATABASE=testing` et ne touchent pas à `eventshbf`.

2. **Faire utiliser à PHPUnit la base de `.env`** (par ex. `eventshbf`)  
   - Retirer ou commenter la ligne `<env name="DB_DATABASE" value="testing"/>` dans `phpunit.xml`.  
   - Les tests utiliseront alors `DB_DATABASE` de `.env`.  
   - **Attention :** avec `RefreshDatabase`, les tests réinitialiseront cette base (migrations + seed) à chaque run. À réserver à une base dédiée au test, pas à ta base de dev principale.

3. **Utiliser SQLite en mémoire pour les tests**  
   - Dans `phpunit.xml`, ajouter par ex.  
     `DB_CONNECTION=sqlite` et `DB_DATABASE=:memory:`,  
     et ne plus imposer `DB_DATABASE=testing`.  
   - Les tests ne dépendent plus de MySQL ni d’une base `testing` à créer.

En résumé : l’application tourne toujours sur ta base ; ce qui “change” en lançant les tests, c’est uniquement le **nom de la base** imposé par `phpunit.xml` pour isoler les tests. Si tu veux, on peut détailler l’une des trois options (création de `testing`, utilisation de la base `.env`, ou passage en SQLite pour les tests).