Étant donné que je ne suis pas vraiment compétent avec des bases de données, certains détails peuvent être irreunvant, mais je vais inclure tout:
Dans le cadre d'un projet de mon université, nous créons un site Web utilisant JSP, Servlets et utilise un serveur MySQL comme backend.
Je suis responsable de la mise en place des tables sur la base de données et de créer les classes Java pour interagir avec elle. Cependant, nous ne pouvons vous connecter qu'au serveur MySQL de l'intérieur de l'université, tandis que nous travaillons tous (7 personnes) surtout à la maison.
Je crée une interface EDIT : Je ne suis pas sûr des différences entre les bases de données SQL, mais évidemment toutes les requêtes que je cours sur MySQL devrait courir sur le moque. Queryhandler qui a une méthode qui prend une chaîne (représentant une requête) et renvoie résultatsset . Ma question est la suivante: Comment créer une classe qui implémente cette interface qui simulera une base de données et permettra aux autres d'utiliser différents dbhandler s et non connaître la différence et permettez-moi de tester différentes requêtes sans se connecter à la base de données mysql actuelle?
5 Réponses :
Pourquoi ne pas simplement installer votre propre base de données MySQL pour tester? Il fonctionne sur Windows, Mac et Linux, et ce n'est pas trop de ressources lourdes. Je l'ai installé sur mon ordinateur portable pour des tests locaux.
Ce ne sera-t-il pas un problème avec des tests unitaires, etc.? Comme le simulé du serveur lui-même ne sera pas dans notre coffre (nous utilisons SVN) - c'est-à-dire que d'autres personnes ne seront pas en mesure de l'utiliser.
@AMIR, chaque ordinateur de développeur doit avoir MySQL dessus. Il est une pratique standard dans le monde réel de fournir une base de données pour le développement. Dans ce cas, mettez les DBS sur les ordinateurs des étudiants.
Si MySQL est une partie standard de l'environnement de développement et que le test de l'unité @Beforeclass s'assure que les tables et les données sont correctement installés, vous êtes doré.
Je n'ai jamais travaillé avec DBS dans une équipe. Pouvez-vous clarifier le flux de travail - comment chaque personne utilise sa version de la DB, comment testez-vous si tout le monde a une DB différente (contentement différent) - ou en variante, comment se synchronisent-ils.
Il devrait y avoir un script qui crée / met à jour la base de données dans le contrôle de la source - chaque base de données du développeur doit être sur la structure actuelle. Soit le script de mise à jour ou le test de l'unité garantit que le contenu requis est là.
Comment ça marche? D'où vient-il les données? Est-ce sauvé quelque part dans le référentiel?
@AMIR, ce que vous rencontrez est un problème de développement de l'équipe de base de données classique; Si vous n'avez pas de multiples installations du système de production (et d'où plusieurs versions) ont des scripts qui mettront une mise à jour incrémentiellement des installations locales de MySQL seront une overcilleuse. Au lieu de cela, faites simplement un processus de paiement Dump de la base de données, puis restaurez la base de données localement (bien sûr sauf si elle est énorme). Cela permettrait aux développeurs de développer et de tester des tests sur la version locale ou la version centrale de la base de données même sur la même réseau local (ce qui peut être bon pour certains tests qui soulignent la DB ou peuvent corrompre des données).
essayez derby . C'est un serveur gratuit que vous pouvez utiliser pour tester, si cela ne vous dérangeait pas de devoir changer de pilotes lorsque vous revenez à SQLServer. Vous pourriez être limité dans le type de questions que vous pouvez exécuter. Je ne sais pas si SQLServer a une syntaxe spéciale en dehors de SQL standard.
Que diriez-vous d'utiliser un HSQLDB pour des tests hors connexion? Il ne se comportera pas exactement comme un dB mysql mais est un rapide en mémoire SQL SQL DB qui devrait satisfaire la plupart de vos besoins.
Le meilleur moyen de mon expérience est plusieurs instances de base de données et ou schémas. Normalement, vous en aurez un pour chaque utilisateur de faire leur développement contre / sanité vérifiant l'application en cours d'exécution, une pour une version automatisée pour les tests d'unité exécutées et idéalement pour chaque utilisateur pour exécuter leurs tests d'unités. Et bien sûr les instances / schémas de démos, test d'intégration. Outre le côté pratial, être capable de procéder à cela garantit le déploiement / la mise à niveau de l'application / de la base de données sera également presque sans faille.
En supposant que vous avez une couche DAO, le seul code qui a besoin d'accès à une base de données réelle au niveau de la vérification de l'unité est la mise en œuvre de la DAO, la couche d'entreprise doit utiliser une implémentation Mock DAO.
Votre API semble être défectueuse. Vous ne devriez pas retourner les résultats dans les clients. Ce faisant, vous forcez toujours vos clients à compter sur un backend de base de données relationnelle. Votre couche d'accès aux données doit masquer tous les détails de la manière dont vos données sont en réalité structurées et stockées.
Au lieu de renvoyer un résultateur, envisagez de renvoyer une liste ou permettez au client de fournir un flux de flux de votre composant d'accès aux données.
Cela effectuera des tests d'unité triviaux pour les clients de l'API et vous permettra d'échanger des mécanismes de stockage à volonté.
Qu'est-ce qui est généralement retourné au lieu de ResultSet? Comment une liste servirait-elle la même fonctionnalité?
Je pense que c'est plus d'effort pour écrire une telle classe que d'obtenir chacun de vos membres de votre groupe à installer MySQL et à configurer la DB sur leurs ordinateurs ... +1 pour la créativité cependant :)