Rails 5.1 Exécution des tests du système sur Puma?

Question

Je me demandais s'il y avait un moyen d'utiliser le serveur Puma (Rails par défaut) JUSTE sur les nouveaux tests du système Rails 5.1?

Actuellement, sur tous nos projets, nous utilisons tiny_tds, mais j'essayais d'expérimenter avec des tests système 5.1 avec Capybara/Selenium mais cela échoue bien sûr parce que je n'ai pas installé/exécuté Puma.

J'ai jeté un oeil à travers la documentation et je n'ai rien vu sur la déclaration du type de serveur que vous voulez utiliser. Je me connectais à une base de données SQL Server, donc je ne sais pas si Puma est capable de le faire (et c'est probablement pourquoi utiliser tiny_tds en premier lieu).

Answer 1

Vous confondez les adaptateurs de base de données et les serveurs Web rack qui sont très différents.

Puma (comme Webrick, Thin, Unicorn, etc.) est un serveur web Rack à usage général. Il s'assoit et attend les demandes entrantes de la part des visiteurs et les envoie à une application (comme une application Rails) en l'appelant avec un hachage contenant l'environnement et la requête. L'application renvoie un tableau contenant la réponse. Le serveur le renvoie au visiteur.

tiny_tds d'autre part est un adaptateur de base de données. Son utilisé pour connecter l'application à la base de données. Le serveur Web est presque totalement inconscient de la façon dont l'application crée une réponse à partir de la requête. Cela inclut toutes les bases de données utilisées.

Dans Rails 5, la plupart des serveurs ne nécessitent pas de configuration. Vous venez d'ajouter la gemme au gemfile et de lancer bundle install et ils se branchent. Il n'y a pas d'étape d'installation séparée.

Ce n'était pas le cas plus tôt, c'est pourquoi Webrick - un serveur avec le seul vrai mérite étant qu'il ne nécessite pas de configuration était la valeur par défaut. C'est maintenant Puma qui contrairement à Webrick est adapté à la production.

L'utilisation de serveurs différents dans des environnements différents n'est pas une bonne idée, car elle viole l'idée de dev/prod parity. Votre environnement de test dev & doit être le plus proche possible de ce que vous déployez afin que vous puissiez détecter les bogues avant qu'ils ne se retrouvent en production. Cela signifie que vous devez utiliser le même serveur, la même base de données, etc.

Exécuter un serveur de test séparé pour différentes parties de votre suite de tests ressemble à une vraie course de poisson - si c'est possible sans piratage de la structure en bits.

Pour SQL Server, il existe activerecord-sqlserver-adapter qui peut utiliser tiny_tds en tant que backend.