-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
REF Tests #174
REF Tests #174
Conversation
Codecov Report
@@ Coverage Diff @@
## master #174 +/- ##
==========================================
+ Coverage 70.14% 70.87% +0.72%
==========================================
Files 114 114
Lines 2820 2822 +2
Branches 283 283
==========================================
+ Hits 1978 2000 +22
+ Misses 719 698 -21
- Partials 123 124 +1
Continue to review full report at Codecov.
|
Je vois que AppVeyor arrive à faire tourner les tests qui reposent sur localdb, ça fait plaisir ! |
[Fact] | ||
public async Task PostShouldNotCallGetByIdOnTheCollection() | ||
{ | ||
using (var storage = _newStorage(Guid.NewGuid().ToString())) | ||
await _fixture.RunCodeInsideIsolatedDatabaseAsync(async (context) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Si ici on créé une db pour chaque test, alors autant se passer de class fixture et passer par une classe de base dont chaque test hérite (on a aucun état partagé entre les tests) : Xunit garanti que le dispose est appelé pour chaque test, donc RunCodeInsideIsolatedDatabaseAsync
deviendrait 1 appel NewDbContext(Guid.NewGuid())
+ Database.EnsureCreated();
dans le constructeur, et Database.EnsureDeleted()
; + context.Dispose()
dans le Dispose de la classe de base.
Ca permettra de rendre le code des tests moins verbeux en retirant tous les appels à RunCodeInsideIsolatedDatabaseAsync
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je suis absolument pour l'option proposée par cette PR, mais contre son utilisation massive sur tous les tests.
Il faut différe
ncier dans les tests ce que l'on teste, je veux dire, parfois on veut vérifier que ça marche bien sur la base SQL d'accord, mais qq fois, on veut vérifier un comportement qqconque sur des objets c# sans préoccupation des requêtes générées.
Egalement les tests aujourd'hui se jouent en moins de 10sec, et cela participe grandement à la qualité du code en général.
1cb5cbf
to
1cd7fa9
Compare
Tests run under a disposable localdb database, with a GUID name. This ensure that SQL constraints will be respected. Tests run in 24 sec now. User now has a Guid identity column in order to avoir IDENTITY_INSERT ON/OFF on localdb database (cf dotnet/efcore#703) I have used a TestFixture to encapsulate the creation/deletion of the database NB : Domain tests could be converted to use InMemoryStorage for faster run
1cd7fa9
to
2e77278
Compare
@Poltuu je me doutais bien que ça ne passerait pas en l'état ;) J'ai fait un effort de refacto, tous les tests sont en inMemory désormais, seul 1 test, celui qui m'intéressait, est en localdb. D'ailleurs j'ai découvert grâce à ce test que le OrderBy natif sur les Guid ne fonctionne pas. Je vais faire une Issue pour ce sujet en particulier. |
Infra.Tests run under a disposable localdb database, with a GUID name. This ensure that SQL constraints will be respected.
User now has a Guid identity column in order to avoir IDENTITY_INSERT ON/OFF on localdb database (cf dotnet/efcore#703)
I have used a TestFixture to encapsulate the creation/deletion of the database
Domain & Web tests still use InMemory C# storage for speed.