|
| 1 | +# Recap des tests API PostgreSQL |
| 2 | + |
| 3 | +Ce document resume les tests effectues apres la migration de l'API de SQL Server vers PostgreSQL. |
| 4 | + |
| 5 | +## Environnement teste |
| 6 | + |
| 7 | +- API ASP.NET Core `net10.0` |
| 8 | +- Base PostgreSQL via Docker Compose |
| 9 | +- Provider ADO.NET : `Npgsql` |
| 10 | +- Migrations automatiques : DbUp avec `dbup-postgresql` |
| 11 | +- Acces data : Dapper |
| 12 | + |
| 13 | +La base PostgreSQL utilisee pendant les tests etait celle du service Docker `postgres`. |
| 14 | +Les secrets locaux, le contenu du `.env` et le fichier Firebase n'ont pas ete affiches ni documentes. |
| 15 | + |
| 16 | +## Demarrage valide |
| 17 | + |
| 18 | +Les points suivants ont ete verifies : |
| 19 | + |
| 20 | +- Le conteneur PostgreSQL demarre et passe en etat `healthy`. |
| 21 | +- Docker Compose est valide avec `docker compose config --quiet`. |
| 22 | +- L'API demarre avec une connection string PostgreSQL. |
| 23 | +- DbUp se lance au demarrage de l'API. |
| 24 | +- DbUp detecte les scripts deja executes et ne rejoue pas les migrations inutilement. |
| 25 | + |
| 26 | +Les scripts DbUp PostgreSQL valides sont : |
| 27 | + |
| 28 | +- `TableMasterApi/sql-scripts/001_InitialSchema.sql` |
| 29 | +- `TableMasterApi/sql-scripts/002_UpdateReservationStatus.sql` |
| 30 | +- `TableMasterApi/sql-scripts/003_AddDeviceTokens.sql` |
| 31 | + |
| 32 | +## Scenarios HTTP testes |
| 33 | + |
| 34 | +Un scenario complet a ete execute en HTTP contre l'API locale, avec creation d'un compte de test, recuperation d'un token JWT, puis appels authentifies. |
| 35 | + |
| 36 | +Routes d'authentification et utilisateur : |
| 37 | + |
| 38 | +- `POST /api/User` : creation de compte |
| 39 | +- `POST /api/Auth` : login |
| 40 | +- `POST /api/Auth/refresh` : renouvellement du refresh token |
| 41 | +- `GET /api/User/{id}` : lecture utilisateur |
| 42 | +- `PUT /api/User` : mise a jour utilisateur |
| 43 | +- `PUT /api/User/Password` : changement de mot de passe |
| 44 | +- `DELETE /api/User` : suppression de compte |
| 45 | + |
| 46 | +Routes restaurant : |
| 47 | + |
| 48 | +- `POST /api/Restaurant` : creation restaurant |
| 49 | +- `GET /api/Restaurant/{id}` : lecture restaurant |
| 50 | +- `GET /api/Restaurant` : recherche restaurants avec pagination et distance |
| 51 | +- `PUT /api/Restaurant/{id}` : modification restaurant |
| 52 | +- `DELETE /api/Restaurant/{id}` : suppression restaurant |
| 53 | + |
| 54 | +Routes tables : |
| 55 | + |
| 56 | +- `POST /api/Table/Restaurant/{id}` : creation table |
| 57 | +- `GET /api/Table/Restaurant/{id}` : lecture tables d'un restaurant |
| 58 | +- `PUT /api/Table/{id}` : modification table |
| 59 | +- `POST /api/Table/Restaurant/{id}/Bulk` : remplacement des tables |
| 60 | +- `DELETE /api/Table/{id}` : suppression table |
| 61 | + |
| 62 | +Routes menu : |
| 63 | + |
| 64 | +- `POST /api/Menu` : creation menu |
| 65 | +- `GET /api/Menu/restaurant/{restaurantId}` : lecture menus d'un restaurant |
| 66 | +- `DELETE /api/Menu/{id}` : suppression menu |
| 67 | + |
| 68 | +Routes horaires : |
| 69 | + |
| 70 | +- `POST /api/DailyActivity` : creation horaire |
| 71 | +- `GET /api/DailyActivity/restaurant/{restaurantId}` : lecture horaires |
| 72 | +- `PUT /api/DailyActivity/{id}` : modification horaire |
| 73 | +- `DELETE /api/DailyActivity/{id}` : suppression horaire |
| 74 | + |
| 75 | +Routes jours de fermeture : |
| 76 | + |
| 77 | +- `POST /api/ClosedDayException` : creation fermeture |
| 78 | +- `GET /api/ClosedDayException/restaurant/{restaurantId}` : lecture fermetures |
| 79 | +- `PUT /api/ClosedDayException/{id}` : modification fermeture |
| 80 | +- `DELETE /api/ClosedDayException/{id}` : suppression fermeture |
| 81 | + |
| 82 | +Routes avis : |
| 83 | + |
| 84 | +- `POST /api/Review` : creation avis |
| 85 | +- `GET /api/Review/Restaurant/{id}` : lecture avis restaurant |
| 86 | +- `GET /api/Review/My` : lecture de mes avis |
| 87 | +- `PUT /api/Review/{id}` : modification avis |
| 88 | +- `DELETE /api/Review/{id}` : suppression avis |
| 89 | + |
| 90 | +Routes reservations : |
| 91 | + |
| 92 | +- `POST /api/Reservation` : creation reservation |
| 93 | +- `GET /api/Reservation` : lecture reservations |
| 94 | +- `GET /api/Reservation/My` : lecture de mes reservations |
| 95 | +- `PUT /api/Reservation/{id}/Status` : changement de statut |
| 96 | +- `DELETE /api/Reservation/{id}` : suppression reservation |
| 97 | + |
| 98 | +Routes device tokens : |
| 99 | + |
| 100 | +- `POST /api/DeviceToken` : enregistrement token appareil |
| 101 | +- `DELETE /api/DeviceToken` : suppression token appareil |
| 102 | + |
| 103 | +## Bug trouve et corrige |
| 104 | + |
| 105 | +Pendant le test de `POST /api/DailyActivity`, l'API retournait une erreur 500. |
| 106 | + |
| 107 | +Cause : |
| 108 | + |
| 109 | +- PostgreSQL renvoie les colonnes SQL `TIME` via `Npgsql` sous forme de `TimeOnly`. |
| 110 | +- Les modeles de l'API utilisent `TimeSpan` pour `StartTime` et `EndTime`. |
| 111 | +- Dapper ne convertissait pas automatiquement `TimeOnly` vers `TimeSpan`. |
| 112 | + |
| 113 | +Correction ajoutee : |
| 114 | + |
| 115 | +- Ajout de `TableMasterApi/DAL/Handlers/PostgresTimeSpanHandler.cs` |
| 116 | +- Enregistrement du handler Dapper dans `Program.cs` |
| 117 | + |
| 118 | +Ce handler convertit : |
| 119 | + |
| 120 | +- `TimeOnly` vers `TimeSpan` en lecture |
| 121 | +- `TimeSpan` vers parametre SQL en ecriture |
| 122 | + |
| 123 | +Apres correction, les routes `DailyActivity` passent. |
| 124 | + |
| 125 | +## Nettoyage des donnees de test |
| 126 | + |
| 127 | +Les donnees creees par les scenarios de test ont ete ciblees avec des prefixes dedies : |
| 128 | + |
| 129 | +- emails `codex.route.*@example.com` |
| 130 | +- emails `codex.password.*@example.com` |
| 131 | +- restaurants `Codex Test Restaurant ...` |
| 132 | +- device tokens `test-device-*` |
| 133 | + |
| 134 | +Les donnees de test `codex.route.*` ont ete nettoyees apres la passe complete. |
| 135 | +Le compte temporaire utilise pour tester le changement de mot de passe a ete supprime via `DELETE /api/User`. |
| 136 | + |
| 137 | +## Commandes de verification executees |
| 138 | + |
| 139 | +```bash |
| 140 | +docker compose config --quiet |
| 141 | +dotnet build TableMasterApi.sln --no-restore |
| 142 | +dotnet test --no-build |
| 143 | +``` |
| 144 | + |
| 145 | +Resultat final : |
| 146 | + |
| 147 | +- Build OK |
| 148 | +- Tests xUnit OK : 31/31 |
| 149 | +- Scenario HTTP complet OK |
| 150 | +- Aucune trace restante de `SqlConnection`, `SqlException`, `DbUp.SqlServer`, `SqlDatabase`, `OUTPUT INSERTED`, `GETDATE()` ou syntaxe SQL Server critique dans `TableMasterApi/` |
| 151 | + |
| 152 | +## Notes |
| 153 | + |
| 154 | +- Les warnings de nullabilite existants ne bloquent pas la migration PostgreSQL. |
| 155 | +- Le package `Microsoft.AspNetCore.SignalR` remonte un warning NuGet indiquant qu'il est probablement inutile, mais ce point n'a pas ete modifie car il est hors scope de la migration. |
| 156 | +- Les tests ont valide le comportement avec une base PostgreSQL locale Docker. Ils ne constituent pas encore une suite automatisee versionnee dans `TableMasterApi.Tests`. |
0 commit comments