C’est une bonne idée de paralleliser, je fais jamais ça. Je viens de tester sur un projet pro et ça a réduit par 5 le temps des tests 😃 à voir au déploiement, je vais voir avec les collègues. je peux te faire un retour si besoin
Salut, c’est pas très réaliste comme use cases. Tu test pas vraiment des méthodes tu fais juste du code en utilisant une entité. Je fais rarement des tests mais je crois que ça marche pas comme ça. Et il me semble qu’on peut aussi mocker une db « in memory » qui serait plus performant pour tester qu’une vrai db. C’est aussi beaucoup mieux pour la CI CD, plus simple
En tout cas c’est intéressant j’aurai pas pensé à utiliser mes CPU pour accélérer les test, mais sur une CICD y’a rarement plusieurs CPU. Je pense qu’il vaut mieux aller sur d’autres méthodes
Dans l'article, j'ai effectivement choisi des exemples simples pour éviter de faire du code à rallonge. Je trouve que ça reste la même problématique. Il faut penser que tu testes tes entités. Si elles ont des comportements particuliers, des properties, des méthodes, etc., tu vas vouloir les tester.
Après, cet exemple s'applique également à des routes. Si je prends l'exemple d'un CRUD, tu vas tester tes routes. Ta route va créer / supprimer / modifier des entités en base de données. Tu ne touches pas directement à tes entités dans ton test, mais ta route touche à ces entités. Il faut donc isoler l'execution de ces tests pour pas qu'ils ne se marchent dessus.
Pour répondre à la partie sur la "in memory database", c'est vrai que tu peux le faire.
Mais, en réalité, tu veux te rapprocher le plus possible de la base de données qui sera utilisée en production. Par exemple, Postgres possède des comportements qui ne sont disponibles que sur Postgres et qui ne sont pas répliquables dans une database in memory. Par exemple, si dans tes modèles tu as une colonne de type ARRAY.
C’est une bonne idée de paralleliser, je fais jamais ça. Je viens de tester sur un projet pro et ça a réduit par 5 le temps des tests 😃 à voir au déploiement, je vais voir avec les collègues. je peux te faire un retour si besoin
Salut, c’est pas très réaliste comme use cases. Tu test pas vraiment des méthodes tu fais juste du code en utilisant une entité. Je fais rarement des tests mais je crois que ça marche pas comme ça. Et il me semble qu’on peut aussi mocker une db « in memory » qui serait plus performant pour tester qu’une vrai db. C’est aussi beaucoup mieux pour la CI CD, plus simple
En tout cas c’est intéressant j’aurai pas pensé à utiliser mes CPU pour accélérer les test, mais sur une CICD y’a rarement plusieurs CPU. Je pense qu’il vaut mieux aller sur d’autres méthodes
Hello !
Dans l'article, j'ai effectivement choisi des exemples simples pour éviter de faire du code à rallonge. Je trouve que ça reste la même problématique. Il faut penser que tu testes tes entités. Si elles ont des comportements particuliers, des properties, des méthodes, etc., tu vas vouloir les tester.
Après, cet exemple s'applique également à des routes. Si je prends l'exemple d'un CRUD, tu vas tester tes routes. Ta route va créer / supprimer / modifier des entités en base de données. Tu ne touches pas directement à tes entités dans ton test, mais ta route touche à ces entités. Il faut donc isoler l'execution de ces tests pour pas qu'ils ne se marchent dessus.
Pour répondre à la partie sur la "in memory database", c'est vrai que tu peux le faire.
Mais, en réalité, tu veux te rapprocher le plus possible de la base de données qui sera utilisée en production. Par exemple, Postgres possède des comportements qui ne sont disponibles que sur Postgres et qui ne sont pas répliquables dans une database in memory. Par exemple, si dans tes modèles tu as une colonne de type ARRAY.
from sqlalchemy.dialects import postgresql
mytable = Table("mytable", metadata,
Column("data", postgresql.ARRAY(Integer, dimensions=2))
)
Tu ne peux pas l'utiliser dans ta database in memory. Donc t'es obligé d'avoir un vrai Postgres qui tourne