LCC 315 - les températures ne sont pas déterministes

[Emmanuel Bernard]

JVM summit, virtual threads, stacks applicatives, licences, déterminisme et LLMs, quantification, deux outils de l'épisode et bien plus encore.

https://lescastcodeurs.com/2024/09/16/lcc-315-les-temperatures-ne-sont-pas-deterministes/

Emmanuel

[alaou...@gmail.com]

Bonjour,

J'aimerais réagir au sujet de la tension qui existe entre le niveau d'isolation des données de test et la durée des tests (environ 18:30 sur l'épisode).

Effectivement, lorsqu'on utilise TestContainer "clé en main" pour monter une base de données de test (e.g. PostgreSQL), on se retrouve avec le dilemme suivant:

- booter une seule base de données pour tous les tests avec le problème d'isolation que cela représente

- booter une base de données par test avec le problème de lenteur associé

Un premier compromis est de toujours rollback au lieu de commiter. Mais cela ne vous permet pas de vérifier le comportement transactionel de votre système. A mon sens, c'est rédhibitoire.

Si vous utilisez PostgreSQL, le compromis idéal (IMO :) ) existe. PostgreSQL a la notion de template de base de données. D'ailleurs, chaque instance de cluster PostgreSQL contient une base de données nommée "template1". Par défaut cette base de données est vide. Elle sert de template pour chaque commande "create database". i.e. si vous ajoutez une table foo à "template1" puis que vous exécutez "create database", votre nouvelle database contiendra la table foo avec les données qui vont avec.

Ainsi, vous pouvez, avant tout test, peupler "template1" avec les structures et données par défaut. Puis créer une database par test. La manière dont Postgres réplique les données de "template1" dans chaque nouvelle database est extrêmement optimisée. 

Cette technique nous permet d'avoir le meilleur des 2 mondes :)

[Arnaud Héritier]

C'est intéressant Alaoui

J'essaierai de le prototyper sur un projet

J'avais utilisé ce type d'approche avec un backend nosql (elastic) puisque la creation des index est ultra-rapide.

J'utilisai des index dédiés à chaque test suite je crois (je ne suis plus sur de la granularité que j'avais choisi).

Effectivement avec un base créer une database c'est cheap et encore plus si tu utilises une template

Merci

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/90af3de7-056d-4827-a657-02fa6f9cc231n%40googlegroups.com.

--

Arnaud Héritier

Twitter/GitHub/... : aheritier

[alaou...@gmail.com]

Intéressant, je testerai aussi avec ElasticSearch.

Réda Housni Alaoui

[Nicolas Labrot]

Team docker compose avec Postgres lancé avant l'exécution de tous les tests. Comme il y a de toute façon le besoin pour le dev local de lancer la stack, le docker compose fait sens et peut être réutilisé.

Avec une database par test comment mets-tu à jour ton connections string/pool ? (je pars du principe que tu ne drop/create pas pour chaque test et que c'est une application type spring avec un context à lancer)

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/2aa6e426-9419-46ea-858e-2e8c5a1e0d28n%40googlegroups.com.

[alaou...@gmail.com]

> Avec une database par test comment mets-tu à jour ton connections string/pool ? (je pars du principe que tu ne drop/create pas pour chaque test et que c'est une application type spring avec un context à lancer)

Oui, on utilise Spring Boot. On a un seul contexte Spring sur l’ensemble des tests. L’environment de test utilise une unique datasource spéciale qui est implémentée comme un routeur vers la datasource effective (e.g. Commons DBCP). Dans notre cas (tendance à penser qu’il s’agit du cas général?), les connections JDBC ne sont pas maintenues entre les tests. A noter que nous n’avons aucun background thread consommateur de connection (e.g. task scheduler) dans le cadre de l’environment de test. 

Dans le cadre d’un test, la demande de connection JDBC est routée vers la datasource associée au test courant. Au début d’un test, la datasource associée au test précédent est fermée pour couper toutes les connections qui seraient restées ouvertes (ce qui serait un bug dans notre cas).

Réda Housni Alaoui

[Emmanuel Lécharny]

Salut!

dès qu'on utilise TC, on est confronté à ce problème...

Il y a 2 ans, quand on a commencé (pour remplacer les tests utilisant
H2, qui est 'compatible' jusqu'à un certain point... lointant!), les
premiers tests lançaient unitairement TC. On avait qq chose comme 200
tests, donc on a vite compris que c'était une erreur (200 x 10s -> 40 mins).

Donc on a décidé de faire des rollbacks, mais comme tu le dis, ça pose
d'autres problèmes. Pour nous, ça faisait largement l'affaire.

Mais il y a aussi une autre possibilité, si la base n'est pas trop
grosse: faire un Snapshot (pg_dump/pg_restore). On ne l'a pas mis en
oeuvre, parce que la methode basée sur des rollbacks étaient suffisante,
mais ça rest eune option.

La suggestion de Arnaud qui consiste à créer une database par test est
également possible, mais il faut la populer avant chaque test. Si la
taille des données à injecter est petire, je pense que le snapshot est
suffisant.


Juste pour info, dans le monde LDAP, on a travaillé longtemps sur ce
sujet sur Apache Directory: comment lancer des tests qui ne prennent pas
des heures (lancement de la base avant chaque test à proscrire pour la
même raison), et du coup on a intégré un mécanisme de journalisation: on
pose un point d'arrêt, on enregistre toutes les opérations ainsi que les
opérations inverses (si on ADD, alors on crée le DELETE inverse) et on
peut retourner dessus (techniquement, on 'joue' les opérations à
l'envers). Je pense qu'il doit y avoir l'équivalent dans Posgresl
(https://www.postgresql.org/docs/current/app-pgrewind.html), mais je
n'ai pas vérifié.

> https://lescastcodeurs.com/2024/09/16/lcc-315-les-temperatures-ne-sont-pas-deterministes/ <https://lescastcodeurs.com/2024/09/16/lcc-315-les-temperatures-ne-sont-pas-deterministes/>

>
> Emmanuel
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com

> <mailto:lescastcodeur...@googlegroups.com>.

> Cette discussion peut être lue sur le Web à l'adresse

> https://groups.google.com/d/msgid/lescastcodeurs/90af3de7-056d-4827-a657-02fa6f9cc231n%40googlegroups.com <https://groups.google.com/d/msgid/lescastcodeurs/90af3de7-056d-4827-a657-02fa6f9cc231n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elec...@apache.org