Je suis conscient que Rabbitmq est écrit à Erlang et ne peut donc pas être intégré dans une JVM comme nous le ferions avec le courtier JMS d'Activemq pour l'exemple.
Mais en réalité, certains projets sont effectués dans une autre langue et qui peuvent facilement être incorporés pour des tests d'intégration.
Pour l'exemple, MongoDB, écrit en C ++, peut être facilement démarré / arrêté dans le contexte d'un test d'intégration JVM avec: https://github.com/frapdoodle-st/embedmongo.flapdoodle.de
Il y a aussi quelqu'un le portant à Java: https://github.com/thiloplanz/jmockmongo/
Je me demande simplement comment pouvons-nous faire des tests d'intégration lorsque ma demande est écrite en Java et que l'autre technologie se trouve dans un autre langage (comme Erlang pour rabbbitmq)?
En général, quelles sont les bonnes pratiques?
Je vois 3 solutions principales:
Y a-t-il un plugin maven / sbt / fourffe pour démarrer un courtier de rabbbitmq temporaire? Tout projet visant à soutenir Junit / Testng Rabbitmq avant une classe de test?
J'ai vu qu'il y a une implémentation d'OpenSource d'AMQP en Java: Apache Qpid Quelqu'un a-t-il une expérience en utilisant cette mise en œuvre pour les tests d'intégration lors de la production il y a une Rabbitmq? Est-ce même possible? J'utilise l'intégration de printemps.
Au fait, je viens de remarquer que le projet Spring-AMQP mentionne sur son GitHub Readme:
Beaucoup de tests "intégration" ici nécessitent un serveur RabbitMQ en cours d'exécution - Ils seront ignorés si le courtier n'est pas détecté.
5 Réponses :
Si c'était moi, je regarderais en moqueur de la composante de pile en question. Quel est le meilleur cadre simulé pour Java? (Bien que ce n'est pas une bonne pile Dépassement de la question) et Objet mock pourrait vous aider à aller.
Mocking Les composants facilitent les tests (IMHO) que d'essayer de tout "test en direct".
Nous utilisons déjà des moqueurs (BTW I Travailler avec un commissaire Makito). Ce test d'intégration vise à vérifier que l'intégration fonctionne. Donc, si j'utilise des simulacres, cette partie n'est plus testée. J'aimerais vérifier que ma configuration cassée fonctionne également avec mon application et non seulement le comportement de l'application.
Dans le passé, j'ai utilisé une machine virtuelle qui avait une nouvelle installation de RabbitMQ en cours d'exécution. Les développeurs le couraient constamment et notre serveur CI démarrerait une nouvelle machine virtuelle pour chaque révision du code. Nos tests échoueraient s'ils ne pouvaient pas se connecter au serveur au lieu de sauter les tests comme un manque d'essais d'intégration constitue un problème grave.
Cela a tendance à travailler raisonnablement bien et empêche de devoir commencer et arrêter la Rabbitmq pour les tests. Nos tests ont été divisés pour utiliser des Vhosts pour l'isolement et quelques appels pour créer des Vhosts à la demande afin que nous puissions parlementer des tests, c'est que nous devions.
Bonne idée. Combien de temps faut-il pour frayer ce vm avec un rabbbitmq?
Avec Vagrant et la base de base, il faut moins de 5 minutes, il s'agissait d'un peu de problème sur la machine CI, de sorte qu'il est reconstruit après que les tests puissent être laissés à l'attente de la prochaine poussée du code. Avec une gestion appropriée de Vhosts, il devrait être possible de laisser le fonctionnement du serveur CI et de la reconstruire la nuit.
J'ai vu qu'il y a un plugin maven vagabond. Besoin d'essayer. Nicoulaj.github.io/ Vagrant-Maven-plugin / exemples / ... Merci, cela semble être le meilleur moyen d'utiliser
J'ai accepté ma propre réponse ici: Stackoverflow.com/a/24919210/82609 parce que l'utilisation de Docker me semble plus appropriée que d'utiliser des vms enfin
Je vais vous dire mon avis sur l'Apache Qpid vs Rabbit MQ comme j'ai travaillé avec les deux. Mon avis est qu'ils «étendent» AMQP, mais sont très différents. Si dans la production, vous aurez la Rabbit MQ, utilisez-le de la même version, de la même version, de la même version, de la même version, des mêmes corrections, etc. Il y a des choses que Apache Qpid peut faire et que la Rabbit MQ ne peut pas et vice-versa.
sting Les tests d'intégration évidents sont effectués afin que vous puissiez tester l'intégration
Oui c'est vrai. BTW il semble que Rabbitmq un courtier AMQP 0.9.1 mais Qpid est 1,0 ...
Je commencerais également une instance de Rabbitmq, mais pour les tests automatisés / CI, comment le démarrez-vous? J'aimerais avoir un plugin Maven pour la phase de test de pré-intégration qui espionne un nouveau serveur de rabbbitmq frais et la ferme après les tests.
Basé sur la réponse de Philip Christiano qui dit d'utiliser des VM's, maintenant nous avons Docker et je pense que c'est la voie à suivre pour intégrer différentes technologies dans des conteneurs Docker.
On peut démarrer un conteneur Docker contenant un serveur rabbbitmq, et il sera plus rapide que d'utiliser les VM's, car les conteneurs Docker sont légers et le temps de démarrage est beaucoup mieux.
Il existe des plugins mavis qui permettent de démarrer des conteneurs Docker, par exemple: http: //www.alexecollins.com/Content/Docker-Maven-Plugin/
Depuis que j'étais dans exactement la même situation et que je ne pouvais pas trouver une bonne solution, je l'ai développé moi-même (inspiré de l'embarquage-Redis, embarqué-Mongo, etc.)
Cette bibliothèque est une enveloppe autour du processus de Téléchargement, extraction, démarrage et gestion de la rabbbitmq afin qu'il puisse fonctionner comme un service intégré contrôlé par n'importe quel projet JVM. P>
Vérifiez-le: https://github.com/alejandrorivera/eMbedded-rabbitmq p>
C'est aussi simple que: p>
EmbeddedRabbitMqConfig config = new EmbeddedRabbitMqConfig.Builder()
.version(PredefinedVersion.V3_5_7)
// ...
.build();
EmbeddedRabbitMq rabbitMq = new EmbeddedRabbitMq(config);
rabbitMq.start();
...
rabbitMq.stop();
Mon expérience en utilisant Apache Qpid d'un autre projet JVM était certainement décevante. Bien qu'il soit possible de démarrer Apache Qpid de cette façon, il n'a pas été conçu pour fonctionner comme celui-ci. QPID, au moment de l'exécution, a reconfiguré l'ensemble du cadre de journalisation de l'application (logback SLF4J +) pour répondre à ses propres besoins et n'a pas été facile de rétablir ce changement. Dans notre cas, nous nous appuyions fortement sur les extensions de lapbitmq, de sorte que cela n'avait plus de sens poursuivre cette avenue.