Exécution de PostgreSQL en mémoire uniquement

Je veux exécuter une petite base de données PostgreSQL qui ne fonctionne qu'en mémoire, pour chaque test unitaire que j'écris. Par exemple:

@Before
void setUp() {
    String port = runPostgresOnRandomPort();
    connectTo("postgres://localhost:"+port+"/in_memory_db");
    // ...
}

Idéalement, je vais avoir un seul exécutable postgres vérifié dans le contrôle de version, que le test unitaire utilisera.

Quelque chose comme HSQL, mais pour postgres. Comment puis je faire ça?

Où puis-je obtenir une telle version de Postgres? Comment puis-je lui dire de ne pas utiliser le disque?

Cela n'est pas possible avec Postgres. Il n'offre pas de moteur en processus / en mémoire comme HSQLDB ou MySQL.

Si vous souhaitez créer un environnement autonome, vous pouvez placer les binaires Postgres dans SVN (mais c'est plus qu'un simple exécutable).

Vous devrez exécuter initdb pour configurer votre base de données de test avant de pouvoir faire quoi que ce soit avec cela. Cela peut être fait à partir d'un fichier de commandes ou en utilisant Runtime.exec (). Mais notez que initdb n'est pas quelque chose de rapide. Vous ne voudrez certainement pas exécuter cela pour chaque test. Vous pourriez vous en sortir avant votre suite de tests.

Cependant, même si cela peut être fait, je vous recommande d'avoir une installation Postgres dédiée où vous recréez simplement votre base de données de test avant d'exécuter vos tests.

Vous pouvez recréer la base de données de test en utilisant une base de données modèle qui rend sa création assez rapide ( beaucoup plus rapide que d'exécuter initdb pour chaque test)

(Déplacer ma réponse de Utiliser PostgreSQL en mémoire et la généraliser):

Vous ne pouvez pas exécuter Pg en cours de traitement, en mémoire

Je ne peux pas comprendre comment exécuter la base de données Postgres en mémoire pour les tests. C'est possible?

Non ce n'est pas possible. PostgreSQL est implémenté en C et compilé en code de plateforme. Contrairement à H2 ou Derby, vous ne pouvez pas simplement charger le jaret le lancer comme une base de données en mémoire jetable.

Contrairement à SQLite, qui est également écrit en C et compilé en code de plate-forme, PostgreSQL ne peut pas non plus être chargé en cours de traitement. Il nécessite plusieurs processus (un par connexion) car il s'agit d'une architecture multitraitement et non multithreading. L'exigence de multitraitement signifie que vous devez lancer le postmaster en tant que processus autonome.

Au lieu de cela: préconfigurer une connexion

Je suggère simplement d'écrire vos tests pour vous attendre à ce qu'un nom d'hôte / nom d'utilisateur / mot de passe particulier fonctionne, et que le test exploite CREATE DATABASEune base de données jetable, puisDROP DATABASE à la fin de la course. Obtenez les détails de connexion à la base de données à partir d'un fichier de propriétés, des propriétés de la cible de construction, d'une variable d'environnement, etc.

Vous pouvez utiliser en toute sécurité une instance PostgreSQL existante dans laquelle vous avez déjà des bases de données qui vous intéressent, tant que l'utilisateur que vous fournissez à vos tests unitaires n'est pas un super-utilisateur, seulement un utilisateur avec des CREATEDBdroits. Au pire, vous créerez des problèmes de performances dans les autres bases de données. Je préfère exécuter une installation PostgreSQL complètement isolée pour tester pour cette raison.

Au lieu de cela: lancez une instance PostgreSQL jetable à des fins de test

Alternativement, si vous êtes vraiment envie que vous pourriez avoir votre harnais de test localiser les initdbet postgresbinaires, exécutez initdbpour créer une base de données, modifier pg_hba.confà trust, courir postgrespour le démarrer sur un port aléatoire, créez un utilisateur, créez un DB, et exécuter les tests . Vous pouvez même regrouper les binaires PostgreSQL pour plusieurs architectures dans un fichier jar et décompresser ceux de l'architecture actuelle dans un répertoire temporaire avant d'exécuter les tests.

Personnellement, je pense que c'est une douleur majeure qui devrait être évitée; il est beaucoup plus facile de configurer simplement une base de données de test. Cependant, c'est devenu un peu plus facile avec l'avènement du include_dirsupport dans postgresql.conf; maintenant, vous pouvez simplement ajouter une ligne, puis écrire un fichier de configuration généré pour tout le reste.

Des tests plus rapides avec PostgreSQL

Pour plus d'informations sur la façon d' améliorer en toute sécurité les performances de PostgreSQL à des fins de test, consultez une réponse détaillée que j'ai écrite sur ce sujet plus tôt: Optimiser PostgreSQL pour des tests rapides

Le dialecte PostgreSQL de H2 n'est pas un véritable substitut

Certaines personnes utilisent à la place la base de données H2 en mode dialecte PostgreSQL pour exécuter des tests. Je pense que c'est presque aussi mauvais que les gens de Rails qui utilisent SQLite pour les tests et PostgreSQL pour le déploiement en production.

H2 prend en charge certaines extensions PostgreSQL et émule le dialecte PostgreSQL. Cependant, c'est juste cela - une émulation. Vous trouverez les zones où H2 accepte une requête mais PostgreSQL qui ne fonctionne pas, où diffère du comportement, etc . Vous trouverez également de nombreux endroits où PostgreSQL prend en charge ce que H2 ne peut tout simplement pas faire - comme les fonctions de fenêtre, au moment de l'écriture.

Si vous comprenez les limites de cette approche et que votre accès à la base de données est simple, H2 peut être OK. Mais dans ce cas, vous êtes probablement un meilleur candidat pour un ORM qui résume la base de données car vous n'utilisez de toute façon pas ses fonctionnalités intéressantes - et dans ce cas, vous n'avez plus à vous soucier de la compatibilité de la base de données.

Les tablespaces ne sont pas la solution!

N'utilisez pas d' espace de table pour créer une base de données «en mémoire». Non seulement cela n'est pas nécessaire car cela n'aidera pas de manière significative les performances de toute façon, mais c'est aussi un excellent moyen de perturber l'accès à tout autre élément qui pourrait vous intéresser dans la même installation PostgreSQL. La documentation 9.4 contient désormais l'avertissement suivant :

AVERTISSEMENT

Même s'ils sont situés en dehors du répertoire de données principal de PostgreSQL, les tablespaces font partie intégrante du cluster de bases de données et ne peuvent pas être traités comme une collection autonome de fichiers de données. Ils dépendent des métadonnées contenues dans le répertoire de données principal et ne peuvent donc pas être attachés à un autre cluster de bases de données ou sauvegardés individuellement. De même, si vous perdez un tablespace (suppression de fichier, panne de disque, etc.), le cluster de base de données peut devenir illisible ou ne pas pouvoir démarrer. Le fait de placer un tablespace sur un système de fichiers temporaire tel qu'un disque virtuel risque de compromettre la fiabilité de l'ensemble du cluster.

parce que j'ai remarqué que trop de gens faisaient cela et avaient des problèmes.

(Si vous avez fait cela, vous pouvez mkdirle répertoire de tablespace manquant pour redémarrer PostgreSQL, puis DROPles bases de données manquantes, les tables, etc. Il vaut mieux ne pas le faire.)

Ou vous pouvez créer un TABLESPACE dans un ramfs / tempfs et y créer tous vos objets.
On m'a récemment signalé un article sur le fait de faire exactement cela sous Linux .

avertissement

Cela peut mettre en danger l'intégrité de l' ensemble de votre cluster de base de données .
Lisez l'avertissement ajouté dans le manuel.
Ce n'est donc qu'une option pour les données non durables.

Pour les tests unitaires, cela devrait fonctionner correctement. Si vous exécutez d'autres bases de données sur la même machine, veillez à utiliser un cluster de base de données distinct (qui a son propre port) pour être sûr.

Il est maintenant possible d'exécuter une instance en mémoire de PostgreSQL dans vos tests JUnit via le composant PostgreSQL intégré d'OpenTable: https://github.com/opentable/otj-pg-embedded .

En ajoutant la dépendance à la bibliothèque intégrée otj-pg ( https://mvnrepository.com/artifact/com.opentable.components/otj-pg-embedded ), vous pouvez démarrer et arrêter votre propre instance de PostgreSQL dans votre @Before et @Afer crochets:

EmbeddedPostgres pg = EmbeddedPostgres.start();

Ils proposent même une règle JUnit pour que JUnit démarre et arrête automatiquement votre serveur de base de données PostgreSQL pour vous:

@Rule
public SingleInstancePostgresRule pg = EmbeddedPostgresRules.singleInstance();

Vous pouvez utiliser TestContainers pour lancer un conteneur Docker PosgreSQL pour les tests: http://testcontainers.viewdocs.io/testcontainers-java/usage/database_containers/

TestContainers fournit un JUnit @ Rule / @ ClassRule : ce mode démarre une base de données dans un conteneur avant vos tests et la déchire ensuite.

Exemple:

public class SimplePostgreSQLTest {

    @Rule
    public PostgreSQLContainer postgres = new PostgreSQLContainer();

    @Test
    public void testSimple() throws SQLException {
        HikariConfig hikariConfig = new HikariConfig();
        hikariConfig.setJdbcUrl(postgres.getJdbcUrl());
        hikariConfig.setUsername(postgres.getUsername());
        hikariConfig.setPassword(postgres.getPassword());

        HikariDataSource ds = new HikariDataSource(hikariConfig);
        Statement statement = ds.getConnection().createStatement();
        statement.execute("SELECT 1");
        ResultSet resultSet = statement.getResultSet();

        resultSet.next();
        int resultSetInt = resultSet.getInt(1);
        assertEquals("A basic SELECT query succeeds", 1, resultSetInt);
    }
}

Il existe maintenant une version en mémoire de PostgreSQL de la société de recherche russe nommée Yandex: https://github.com/yandex-qatools/postgresql-embedded

Il est basé sur le processus d'intégration de Flapdoodle OSS.

Exemple d'utilisation (à partir de la page github):

// starting Postgres
final EmbeddedPostgres postgres = new EmbeddedPostgres(V9_6);
// predefined data directory
// final EmbeddedPostgres postgres = new EmbeddedPostgres(V9_6, "/path/to/predefined/data/directory");
final String url = postgres.start("localhost", 5432, "dbName", "userName", "password");

// connecting to a running Postgres and feeding up the database
final Connection conn = DriverManager.getConnection(url);
conn.createStatement().execute("CREATE TABLE films (code char(5));");

Je l'utilise depuis un certain temps. Ça marche bien.

MISE À JOUR : ce projet n'est plus activement maintenu

Please be adviced that the main maintainer of this project has successfuly 
migrated to the use of Test Containers project. This is the best possible 
alternative nowadays.

Vous pouvez également utiliser les paramètres de configuration PostgreSQL (tels que ceux détaillés dans la question et la réponse acceptée ici ) pour obtenir des performances sans nécessairement recourir à une base de données en mémoire.

Si vous utilisez NodeJS, vous pouvez utiliser pg-mem (avertissement: je suis l'auteur) pour émuler les fonctionnalités les plus courantes d'une base de données postgres.

Vous disposerez d'une base de données en mémoire complète, isolée et indépendante de la plate-forme, répliquant le comportement PG (elle fonctionne même dans les navigateurs ).

J'ai écrit un article pour montrer comment l'utiliser pour vos tests unitaires ici .