Comment faire pour simuler un DB pour les tests (Java)?

Java est livré avec Java DB.

Cela dit, je vous déconseillons d'utiliser un autre type de DB que ce que vous utilisez dans la production, sauf si vous passez par un ORM couche. Sinon, votre SQL n'est peut être pas de la croix-plate-forme que vous le pensez.

Également vérifier DbUnit

Il y a beaucoup de points de vue sur la façon de tester l'intégration des points tels que la connexion de Base de données via SQL. Mon ensemble de règles qui a bien fonctionné pour moi, est comme suit:

1) Séparer la Base de données d'accéder à la logique et les fonctions générales de la logique métier et de le cacher derrière une interface.
Raison: afin de tester la grande majorité de la logique du système, il est préférable d'utiliser un mannequin/stub en place de la base de données comme sa plus simple expression.
Raison 2: Il est beaucoup plus rapide

2) Traiter les tests dans la base de données des tests d'intégration qui sont séparés du corps principal de tests unitaires et besoin pour exécuter un programme d'installation de la base de données
Raison: la Vitesse et de la qualité des tests de

3) Tous les développeurs ont besoin de leur propre base de données. Ils auront besoin d'un système automatisé de mise à jour de sa structure basée sur les modifications de leurs coéquipiers et de présenter des données. Voir les points 4 et 5.

4) Utiliser un outil comme http://www.liquibase.org pour gérer les mises à niveau dans vos bases de données de la structure.
Raison: vous Donne de l'agilité dans la capacité de modifier la structure actuelle et aller de l'avant dans les versions

5) Utiliser un outil comme http://dbunit.sourceforge.net/ pour gérer les données. Configurer les fichiers de scénario (xml ou XLS) pour notamment des cas de test et des données de base et claires de ce qui est nécessaire à un cas de test.
La raison: Beaucoup mieux qu'à la main de l'insertion et de suppression de données
Raison 2: plus Facile pour les testeurs de comprendre comment ajuster les scénarios
Raison 3: Son plus rapide pour exécuter cette

6) Vous avez besoin de tests fonctionnels, qui ont aussi des DBUnit tout comme le scénario de données, mais ce sont de loin les plus grands ensembles de données, et l'exécution de l'ensemble du système. Ceci termine l'étape de combiner les connaissances que
a) L'unité exécution des tests et donc la logique est bonne
b) Que les tests d'intégration à la base de données, exécuter et SQL est correcte
résultant dans "et l'ensemble du système fonctionne comme un haut vers le bas de la pile"

Cette combinaison m'a bien servi jusqu'à présent pour atteindre une haute qualité des tests et des produits ainsi que le maintien de la vitesse de test de l'unité de développement et de l'agilité au changement.

Si vous utilisez Oracle au travail, vous pouvez utiliser le Point de Restauration dans les Flashback fonctionnalité de Base de données pour la base de données de retour d'un temps avant de vos tests. Cela va effacer toutes les modifications que vous faites personnellement à la DB.

Voir:

https://docs.oracle.com/cd/E11882_01/backup.112/e10642/flashdb.htm#BRADV71000

Si vous avez besoin d'une base de données de test pour une utilisation avec l'Oracle de production/travail de recherche de la XE, express edition base de données d'Oracle. Ce service est gratuit pour un usage personnel, avec une limite de base de données de moins de 2 go en taille.

Je suis d'accord avec banjollity. La configuration de développement isolé des environnements de test et devrait être une priorité élevée. Chaque système de base de données que j'ai utilisé est soit open source ou libre developer edition, vous pouvez installer sur votre poste de travail local. Cela vous permet de vous développer à l'encontre de la même base de données dialecte de la production, vous donne le plein accès admin pour le développement de bases de données et est plus rapide que d'utiliser un serveur distant.

Nous sommes en train de créer une base de données de test de l'environnement au travail dès maintenant. Nous sentons que nous devons utiliser un réel système de gestion de base avec données simulées. Un problème avec une simulation de SGBD SQL jamais vraiment totalement gélifié comme un standard, donc artificielle, essais d'environnement aurait à soutenir fidèlement notre base de données de production du dialecte. Un autre problème est que nous faisons un usage intensif de la valeur de la colonne contraintes, les contraintes de clés étrangères, et les contraintes unique, et depuis artificielle outil ne serait probablement pas mettre en œuvre ces, nos tests unitaires pourrait passer, mais notre système de tests échouent quand ils ont d'abord frappé les contraintes réelles. Si les tests sont trop longues, cela indique une erreur d'implémentation et de nous régler nos requêtes (généralement des ensembles de données de test sont minuscules par rapport à la production).

Nous avons installé un vrai SGBD sur chaque ordinateur du développeur et sur notre intégration continue et le serveur de test (nous utilisons Hudson). Je ne sais pas ce que votre travail de la politique de restriction, mais il est assez facile à installer et à utiliser PostgreSQL, MySQL et Oracle XE. Ces sont tous gratuits pour le développement de l'utilisation (même Oracle XE), donc il n'y a aucune raison rationnelle à interdire leur utilisation.

La question clé est de savoir comment pouvez-vous garantir que les tests de toujours commencer avec la base de données dans un état cohérent? Si les tests étaient tous en lecture seule, pas de problème. Si vous pouviez ingénieur mutation des tests de toujours lancer dans des opérations qui ne sont jamais commettre, pas de problème. Mais en général, vous avez besoin de s'inquiéter à propos de l'inversion des mises à jour. Pour ce faire, vous pouvez exporter l'état initial vers un fichier, puis de l'importer retour post-test (Oracle de l'exp et de la pmi, des commandes shell ce faire). Ou vous pouvez utiliser un point de contrôle/restauration. Mais d'une façon plus élégante est d'utiliser un outil comme dbunit, qui fonctionne bien pour nous.

Le principal avantage de cela est que nous sommes en mesure de capturer plus de bugs à l'avant où ils sont beaucoup plus faciles à corriger et notre véritable test de système n'est pas bloqué pendant que les développeurs fébrilement essayez de déboguer des problèmes. Cela signifie nous produisons un code de meilleure qualité plus rapidement et avec moins d'effort.

Je pense que mon Acolyte cadre peut être utilisé pour de telles DB maquette: https://github.com/cchantep/acolyte .

Il permet de lancer Java (pour les tests) avec les connexions de vous l'homme de requête/mise à jour de la manipulation: de retour appropriée des jeux de résultats, nombre de mise à jour ou d'avertissement en fonction de l'exécution des cas.

jOOQ est un outil qui, en plus d'offrir d'abstraction SQL a aussi des petits outils intégrés comme un SPI qui permet de se moquer de la totalité de JDBC. Cela peut fonctionner de deux manières comme indiqué dans ce post de blog:

Par la mise en œuvre de la MockDataProvider SPI:

//context contains the SQL string and bind variables, etc.
MockDataProvider provider = context -> {

    //This defines the update counts, result sets, etc.
    //depending on the context above.
    return new MockResult[] { ... }
};

Dans le ci-dessus la mise en œuvre, par programme d'interception de toutes les instructions SQL et retourne le résultat, et ce, même de façon dynamique par "analyse" de la chaîne SQL pour extraire des prédicats /informations sur la table, etc.

À l'aide de la plus simple (mais moins puissant) MockFileDatabase

... qui a un format tel que la suite (un jeu de déclaration /résultat paires):

select first_name, last_name from actor;
> first_name last_name
> ---------- ---------
> GINA       DEGENERES
> WALTER     TORN     
> MARY       KEITEL   
@ rows: 3

Le fichier ci-dessus peuvent alors être lus et utilisés comme suit:

import static java.lang.System.out;
import java.sql.*;
import org.jooq.tools.jdbc.*;

public class Mocking {
    public static void main(String[] args) throws Exception {
        MockDataProvider db = new MockFileDatabase(
            Mocking.class.getResourceAsStream("/mocking.txt");

        try (Connection c = new MockConnection(db));
            Statement s = c.createStatement()) {

            out.println("Actors:");
            out.println("-------");
            try (ResultSet rs = s.executeQuery(
                "select first_name, last_name from actor")) {
                while (rs.next())
                    out.println(rs.getString(1) 
                        + " " + rs.getString(2));
            }
        }
    }
}

Avis de la façon dont on utilise l'API JDBC directement, sans connexion à une base de données.

Ne remarque, je travaille pour le vendeur de jOOQ si cette réponse est biaisée.

Méfiez-vous, à un certain point, vous êtes à la mise en œuvre d'un ensemble de base de données

Les travaux ci-dessus pour les cas simples. Mais méfiez-vous que, finalement, vous allez mettre en œuvre une base de données entière. Vous souhaitez:

1. Vérifier la syntaxe SQL.

OK, en se moquant de la base de données comme indiqué ci-dessus, vous pouvez vérifier la syntaxe, parce que chaque syntaxe que vous n'avez pas prévu dans le exacte version comme indiqué ci-dessus sera rejetée par ces moqueries approche.

Vous pourriez mettre en œuvre un analyseur qui analyse le SQL (ou, encore, l'utilisation de jOOQ), puis de transformer l'instruction SQL dans quelque chose que vous pouvez plus facilement reconnaître et de produire un résultat. Mais en fin de compte, cela signifie simplement que la mise en œuvre d'une base de données entière.

1. Plus important encore, de vérifier que les données sont sélectionnées, mis à jour correctement inséré, selon une situation donnée.

Ce qui rend les choses encore plus difficile. Si vous exécutez une insertion et ensuite mettre à jour, le résultat est évidemment différente de d'abord mettre à jour, puis insérer, comme la mise à jour peut ou peut ne pas affecter la ligne insérée.

Comment vous assurez-vous que ce qui se passe quand "moqueur" une base de données? Vous avez besoin d'une machine d'état qui se souvient de l'état de chaque "moqué" de la table. En d'autres termes, vous allez mettre en œuvre une base de données.

Moqueur ne vous prendra pas plus loin

Comme piotrek mentionné, trop, en se moquant ne vous prendra pas plus loin. Il est utile dans les cas simples lorsque vous avez besoin d'intercepter seulement quelques très connu des requêtes. Il est impossible, si vous voulez vous moquer de la base de données pour l'ensemble d'un système. Dans ce cas, l'utilisation d'une base de données réelle, idéalement le même produit que vous utilisez dans la production.