Open rducom opened 6 years ago
OK, je vois, on limite le nb de résultats mais on n'ordonne pas, ce qui n'est pas logique.
On pourrait orderby id desc
ça me semble le plus pertinent pour la majorité des cas (sauf si on a des GUID comme identifiants)
@rducom je n'arrive pas à reproduire le pb même avec un test Web avec une base EF InMemory.
Ca sous entend que InMemory n'est pas assez proche de la "réalité" on dirait.
Est-ce qu'on pourrait passer sous SQLLite ou une autre alternative qui permettrait à la fois d'avoir la souplesse de InMemory de EF tout en étant encore plus proche de ce qui peut se passer en prod sur une base SQL Server ?
Oui SQLite c'est tout à fait possible. Pour autant c'est loin d'être garanti qu'on chope le même message d'erreur. On peut aussi utiliser localDB (SQL express est installé sur appveyor, suffit de le provisionner dans le yaml). Pour récupérer le message d'erreur, j'ai une astuce pour Hooker les logs de xunit. A noter que inmemory et d'autres providers sont complémentaires : il suffit de piloter la variable "environnement" et switcher selon la valeur. Ce serait d'ailleurs très pertinents de démultiplier les tests d'intégration sur l'ensemble des providers disponibles.
J'ai suivi ce tuto et installé Sqlite, ça m'a l'air pas mal : https://garywoodfine.com/entity-framework-core-memory-testing-database/
J'ai plein d'erreurs, je vais essayer d'aller au bout.
Et en effet faudra qu'on fasse une passe : inMemory, Relational, etc..
Je suis passé sur SQLite mais ce n'est pas mieux, tous les tests sont verts alors qu'ils devraient planter à cause du paging à 10 éléments sachant qu'il n'y a pas de order by.
Je vais chercher un SQLExpress ou autre.
Attention, le message que je remonte est un warning, pas un plantage.
warn: Microsoft.EntityFrameworkCore.Query[10102]
Pour choper ce warn, y'a moyen de hooker les logs de Xunit sur un logger, mais je pense que c'est overkill comme assertion pour un TU. Checker qu'il existe une clause order by dans l'expression sera plus simple je pense.
OK je vois. Je passe sur localdb, ça a l'air de faire le job
Wow, localdb qui marche enfin, c'est beau de voir chaque test jouer de façon isolée sur SA petite base de données ;)
Par contre je ne reproduis toujours pas le pb de paging sans orderby default ! Mais bon je devrais maintenant y arriver !
Bon, au départ je voulais resolve cette issue, mais après avoir fait tout ça : https://github.com/LuccaSA/RestDrivenDomain/pull/174, je me rends compte que ça n'a rien à voir !
L'issue ici suggère d'ajouter un OrderBy par défaut dans les Repo. Le pb c'est qu'il faudrait avoir l'Id de l'entité sous la main, ce qui n'est pas le cas puisque les Repo n'ont pas la contrainte TKey, étant donné qu'ils peuvent travailler sur des classes qui n'ont pas d'ID.
A mon avis ce n'est pas très grave que le Skip/Take prenne 10 entrées "au hasard", car la plupart du temps un consommateur mettra explicitement un orderby dans ses queries pour obtenir ce qu'il veut vraiment.
Donc je suggère qu'on close cette issue.