web-dev-qa-db-fra.com

De bons exemples de concombre à l'état sauvage?

J'ai essayé Cucumber pour quelques projets il y a quelques années et je cherche à l'essayer. Je n'ai pas vraiment besoin d'un autre article "Beginning Cucumber". Au lieu de cela, j'aimerais voir quelques utilisations réelles dans la nature, une que les autres utilisateurs de Cucumber considéreraient comme idiomatique et sans motif.

Donc, à votre avis, quels sont les meilleurs exemples de spécifications de concombre réelles dans les grands projets?

rubycucumberbdd
60
AndrewO

Vous pouvez lire diaspora tests de concombre. C'est un assez gros projet, donc je pense que vous pouvez en tirer quelque chose.

36
Vasiliy Ermolovich

Vous pouvez lire les fonctionnalités de Cucumber lui-même, les gars devraient savoir ce qu'ils font:

https://github.com/cucumber/cucumber-Ruby/tree/master/features

17
Michael Kohl

Ce n'est pas une réponse directe, mais je ne suis pas d'accord avec une prémisse dans votre question, mais j'ai une solution, donc je vais quand même donner mon avis.

celui que les autres utilisateurs de concombre considéreraient idiomatique et sans motif

Cette déclaration, je pense, est malheureusement impossible à satisfaire.

Voici les Gardiens de Brandon de CollectiveIdea qui adoptent une position commune selon laquelle vous devriez tendre vers des étapes génériques et réutilisables , ce qui est logique d'un point de vue général "Ne vous répétez pas".

Cependant, voici Aslak Hellesøy, l'auteur de Cucumber, qui partage également une opinion commune (mais mutuellement exclusive) selon laquelle vous devez vous efforcer de suivre des étapes spécifiques au scénario , ce qui est logique du point de vue de "pourquoi Cucumber at tout?"

À partir de "The Training Wheels Came Off" lié ci-dessus, Aslak fait deux exemples de scénarios pour contraster de manière poignante les deux styles: étapes réutilisables vs spécifique au scénario .

Après des années d'utilisation du concombre dans les deux styles et compte tenu du dilemme ci-dessus, voici mes conclusions:

  1. Les étapes réutilisables deviennent un cauchemar de maintenance car vous devez prendre en charge des définitions d'étapes plus complexes tout en évitant les conflits de noms.
  2. Les étapes spécifiques au scénario sont préférées pour la lisibilité et la simplicité, mais deviennent également un cauchemar de maintenance juste en raison de conflits de noms.

J'ai donc décidé que le concombre est actuellement cassé et que le Capybara ordinaire au-dessus de votre cadre de test unitaire préféré est le plus flexible.

Le concombre pourrait, s'il le souhaitait, ajouter des contextes de scénario, des scénarios spécifiques à une fonctionnalité, des espaces de noms de scénario, etc. de sorte que vous puissiez étendre vos scénarios d'une manière ou d'une autre - par fonctionnalité, rôle d'utilisateur, tout ce qui est logique - et réduire considérablement les conflits de dénomination pour effectuer des étapes spécifiques au scénario vraiment viable. À ce stade, je pense qu'il y aurait un gagnant stylistique clair. Jusque-là, il y aura toujours cette tension de devoir abstraire vos étapes pour éviter les conflits de dénomination vs vouloir les garder spécifiques au scénario pour la simplicité et la lisibilité.

Un autre projet qui tente de remédier à ces lacunes est Spinach , mais le projet n'est pas si actif. Voir mes commentaires ici sur une évaluation des épinards vs concombre .

11
Woahdae

Je cherchais également des projets Cucumber. Et en fait, il y a une page wiki sur le référentiel de Cucumber avec une liste de ces projets ( tous n'utilisent pas encore Cucumber ):

Projets utilisant du concombre:

Source: https://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber

8
Kirill Zhukov

Je recommande:

https://github.com/teambox/teambox/tree/dev/features

Mise à jour: Comme mentionné par Ivailo Bardarov, ils utilisent des étapes Web, ce qui est une mauvaise pratique à l'heure actuelle. Regardez-le comme une référence pour voir les bonnes fonctionnalités et non les étapes!

Mise à jour 2: Je pense que tardivement, j'ai beaucoup appris des fonctionnalités de concombre suivantes fournies avec la version payante d'Object sur Rails livre. Le code source n'est pas open-source, donc je ne peux pas le poster ici ou n'a pas pu trouver un lien vers celui-ci.

Ma façon préférée est de garder le langage des fonctionnalités proche du domaine/langage professionnel plutôt que d'étapes spécifiques ou de remplir le formulaire. Donc, au lieu d'avoir quelque chose comme ça dans mes fonctionnalités:

When I fill in "Name" with "XYZ

Je vais faire dire à ma fonctionnalité

When I create a project:
| name |
| xyz  |

Et puis mon étape aurait, le code pour cliquer sur le lien, analyser la table et remplir le champ de formulaire approprié, etc.

6
Chandresh Pant

Nous utilisons Cucumber sur mon projet actuel pour une refonte de l'application Web, mais ce n'est pas open source, donc je ne peux pas offrir un ensemble réel de fonctionnalités et d'étapes.

Je dirai que nous avons été fortement inspirés par le modèle des objets de page dans ces deuxéchantillons . Nous sommes en plein refactoring de l'interface utilisateur avec notre équipe UX. L'utilisation d'objets de page a rendu l'adaptation des tests à ces changements relativement simple.

3
Mike Cornell

J'aimerais pouvoir publier celles de notre référentiel d'entreprise (application Web interne massive pour un Fortune 500).

Le meilleur à l'état sauvage est probablement les tests de Wikipedia:

https://github.com/wikimedia/qa-browsertests

Vous devez vraiment résumer avec des objets de page. Même lorsque votre application dépasse les 30 écrans de saisie, vos tests deviennent difficiles à résumer.

J'ai une manière expérimentale d'abstraire rapidement des chemins communs sans cycles; devrait probablement le nettoyer et l'envoyer en tant que pull request à Cheezy: https://github.com/cheezy/page-object

3
Chad Brewbaker

Un problème commun avec les grands projets est que les fonctionnalités de Cucumber prennent beaucoup de temps à écrire.

Il y a donc un certain nombre de stratégies impliquées: Si vous utilisez Cucumber pour décrire un système hérité, vous obtenez une couverture de test d'acceptation décente via le concombre et le capybara, puis remaniez vos définitions d'étape de concombre.

Si vous effectuez des tests unitaires correctement, utilisez Cucumber pour décrire uniquement le chemin heureux de votre application, ou uniquement les chemins essentiels non heureux. Obtenez une couverture avec RSpec (ou Xunit de votre choix).

Le principal problème avec Cucumber est que les fonctionnalités doivent décrire la fonctionnalité à un niveau très élevé. Vous devez rendre vos définitions d'étape DRY et réutilisables, et je suis un fan de la redirection des définitions d'étape pour garder les fonctionnalités intéressantes pour les parties prenantes concises et pertinentes. Bien que je pense que ce point peut être un peu controversé.

2
Richard Conroy