À l'extérieur-dans la BDD (avec Specflow)

Question

Je suis nouveau à la BDD, mais je l'ai trouvé très intéressant et qui souhaitent développer mon prochain projet à l'aide de BDD. Après une recherche sur google et regarder des screencasts j'ai encore beaucoup de questions sur la BDD dans la vraie vie.

1. Déclarative ou Impérative scénarios?

La plupart de donné-quand-ensuite, les scénarios que j'ai vu étaient écrits en termes d'INTERFACE utilisateur (impératif).

Scenario: Login
     Given I am on the Login-page
     When I enter 'AUser' in the textbox 'UserName'
       And I enter 'APassword' in the textbox 'Password'
       And I click the 'Login' button
     Then I should see the following text 'You are logged in'

J'ai trouvé ces tests extrêmement fragiles et elles ne disent rien sur la valeur de l'entreprise de cliquer sur des boutons. Je pense que son cauchemar à maintenir. Pourquoi la plupart des exemples d'utilisation de l'impératif scénarios?

Scenario: Login (declarative)
     Given I am not logged in
     When I log in using valid credentials
     Then I should be logged in

Si vous préférez le style déclaratif, comment décririez-vous ces trucs comme "page d'Accueil" ou "Produits" page d'?

• Conseils pour la rédaction des spécifications

2. L'exercice de l'INTERFACE utilisateur ou pas?

La plupart des étapes implémentations je l'ai vu utilisé WatiN, Blanc ou quelque chose comme ça pour mettre en place des scénarios du point de vue des utilisateurs. Démarrage du navigateur, en cliquant sur les boutons. Je pense que c'est extrêmement lent et fragile. Eh bien, je peux utiliser quelque chose comme objet de Page pour faire des tests moins fragile. Mais c'est une autre quantité de travail. En particulier pour les applications de bureau avec une INTERFACE utilisateur complexe.

Comment voulez-vous mettre en œuvre des scénarios de la vie réelle des projets - l'exercice de l'INTERFACE utilisateur, ou par l'essai contrôleurs/présentateurs?

• La meilleure manière d'appliquer la BDD

3. Véritable base de données ou pas?

Lors de la partie Donnée du scénario est mis en œuvre, souvent, il a besoin de certaines données dans le système (par exemple, certains produits de la boutique d'applications). Comment voulez-vous mettre en œuvre cette partie - l'ajout de données à la base de données réelle (pleine de bout en bout, les tests), ou de fournir référentiel talons de contrôleurs?

D'attente pour les réponses!

Mise à JOUR: Ajout de liens utiles sur les questions.

Answer 1

1. Declaritive est la bonne façon, de l'OMI. Si vous êtes parle la page .aspx les noms de fichier, vous le faites mal. Le but de l'histoire est de faciliter la communication entre les développeurs et les non-develoeprs. Les Non-développeurs ne se soucient pas de produits.aspx, qu'ils se soucient de la fiche produit. Votre système n'est quelque chose que les non-développeurs de trouver de la valeur dans. C'est ce que vous essayez de capturer.

2. Eh bien, les histoires dites-le haut niveau de fonctionnalités dont vous avez besoin pour mettre en œuvre. Ses ce que votre système doit faire. La seule façon de vraiment savoir si vous avez fait cela est en fait l'exercice de l'INTERFACE utilisateur. BDD SpecFlow histoires à moi de ne pas remplacer les tests unitaires, plutôt qu'ils sont, vous êtes des tests d'intégration. Si vous cassez cela, vous avez cassé la valeur de l'entreprise obtient à partir de votre logiciel. Les tests unitaires sont des détails de mise en œuvre de vos utilisateurs ne se soucient pas, et ils n'tester chaque morceau dans l'isolement. Que ne peux pas vous dire si A et B fait travailler tout le temps ensemble (en théorie, il devrait, dans la pratique intéressante [lire: inattendue] choses qui arrivent quand vous avez les deux parties à jouer les uns avec les autres). Automatisé de bout en bout les tests peuvent vous aider avec la QA ainsi. Si une zone fonctionnelle des pauses, vous le savez, et ils peuvent passer leur temps dans d'autres domaines de l'application pendant que vous déterminer ce qui a brisé les tests d'intégration.

3. C'est une question délicate. Nous avons fait une approche hybride. Nous utilisons la base de données (intégrer les tests après tous les test le système fonctionne comme une chose, plutôt que les composants individuels), mais plutôt que de réinitialiser les configurations de tous les temps, nous utilisons Deleporter pour remplacer nos référentiels avec Moqs lorsque nous en avons besoin. Semble fonctionner ok, mais il ya certainement des avantages et des inconvénients dans les deux cas. Je pense que nous sommes encore largement essayant de nous-mêmes.

Answer 2

Edit: j'ai trouvé cet article seulement maintenant décrire la notion de limiter vous-même à parler seulement sur des domaines spécifiques afin d'éviter fragile scénarios.

Son principal argument est que le nombre minimal de domaines, vous pouvez parler du domaine du problème, et la solution de domaine. Si vous parlez de quelque chose en dehors de ces deux domaines, alors vous impliquer trop d'intervenants, d'introduire trop de bruit, et de vous rendre vos scénarios fragile.

Il mentionne également un absolu "déclaratif" ou "impératif" modèle d'être un mythe. Il parle d'une cognative modèle appelé "chunking", en disant qu'à toute votre niveau d'abstraction, vous pouvez "morceau" ou "mettre bas". Cela signifie que vous pouvez obtenir plus explicite (comment?) ou plusieurs méta (ce qui ou pourquoi?). Vous morceau à partir d'un impératif modèle en demandant: "que faisons-nous?" Vous morceau vers le bas en disant: "comment allons-nous faire cela?" Donc je suppose que je n'aurais pas trop accroché sur déclarative vs impératif - il ne sera pas vous obtenir n'importe où autant que ce problème va.

Ce que vous obtiendrez quelque part à l'est de déterminer les domaines dont chaque terme appartient, et éventuellement par l'identification des parties prenantes est l'expert pour le domaine que ce terme appartient. Une fois que vous avez identifié tous les domaines, vous pouvez choisir des termes connexes qui sont dans l'un des scénario les plus éminents de domaines, ou de supprimer des non-côté d'états entièrement. Si ce n'est pas suffisant, vous pouvez partager jusqu', préciser, ou de déplacer le scénario de sorte qu'il peut satisfaire à ces exigences.

BTW, il utilise également le scénario de se connecter sur une INTERFACE utilisateur, de sorte que vous avez une orientation concrète :)

Avant la modification: (une partie de cette s'applique toujours. Le "DB ou pas de DB" et "UI ou non de l'INTERFACE utilisateur" des questions sont indépendantes)

1 - Déclarative ou Impérative scénarios?

Déclarative quand vous le pouvez, alors impératif a une certaine valeur (à certaines étapes du cycle de vie du projet).

L'impératif est un moyen plus facile de penser pour les testeurs et les analystes d'affaires qui ne sont pas familiers avec la théorie de l'information et de la conception. Il est aussi plus facile de penser plus tôt dans un projet, avant même que vous avez cloué en bas de votre problème de domaine et des flux de travail. Il peut être utile pour la pensée exploratoire.

Déclarative est moins sujet à changement au cours du temps. Depuis une interface graphique est la partie d'une application plus soumis à des taux de désabonnement à un coup de tête, ce qui est extrêmement précieux. Il est plus facile de réfléchir une fois que vous avez identifié votre problème de domaine et des flux de travail, et qui sont plus concentrés sur relationnelle de concepts. Il est plus stable et plus généralement de modèle applicable.

Si vous écrivez des cas de test avec un médicament générique et un modèle déclaratif, vous pourriez les mettre en œuvre à l'aide de n'importe quelle combinaison de la pleine application de la GUI de l'automatisation, les tests d'intégration, ou des tests unitaires.

comment vous décrire de tels trucs comme "page d'Accueil" ou "Produits" page d'?

Je ne suis pas sûr que je serais au niveau de la base de caractéristiques et les exigences. Vous pouvez faire des sous-fonctions et sous-exigences qui décrivent les détails de mise en œuvre, à l'instar de l'INTERFACE utilisateur spécifique des flux de travail. Si vous êtes à la description d'un morceau de l'INTERFACE utilisateur, alors vous devriez être la définition d'une fonctionnalité de l'INTERFACE utilisateur/exigence.

2 - l'Exercice de l'INTERFACE utilisateur ou pas?

Les deux.

Je pense que c'est extrêmement lent et fragile

Oui, il est. Exécuter toutes les tâches de haut niveau scénario/exigence avec l'INTERFACE utilisateur et le plein DB intégration, mais ne faites pas d'exercice chaque code unique chemin avec la fin à la fin UI automation, et certainement pas des cas limites. Si vous le faites, vous passerez plus de temps à arriver au travail, et beaucoup moins de tests de votre application.

Vous pouvez l'architecture de votre application, de sorte que vous pouvez le faire à moindre coût des tests d'intégration, y compris d'une seule pièce de l'INTERFACE utilisateur en fonction des tests. Les tests unitaires sont également précieux.

Mais la moins de tests d'intégration vous le faites, plus le front-gifles bugs que vous allez manquer. Il peut être plus facile d'écrire des tests unitaires, et ils seront certainement moins fragiles, mais vous allez tester votre application, par définition.

3 - Réel de la base de données ou pas?

Les deux.

Haut niveau de bout en bout, les tests d'intégration doit être fait avec l'ensemble du système en place. Cela comprend un réel DB, l'exécution de vos tests avec chaque système sur un autre serveur, etc.

Le niveau inférieur, vous obtenez, plus je défends les objets fantaisie.

• Les tests unitaires doivent seulement tester les différentes classes
• À mi-niveau des tests d'intégration devraient éviter de coûteux, fragiles, percutants, dépendances, telles que le système de fichiers, bases de données, le réseau, etc. Essayez de tester la mise en œuvre de ces fragiles et percutants, des dépendances avec les tests unitaires et de bout en bout tests seulement.

Answer 3

Au lieu de mentionner une page par nom, décrire ce qu'il représente, par exemple

Scenario: Customers logs in successfully

  When I log in
  Then I should see an overview of ACME's top selling products

Vous pouvez tester directement à l'encontre de sous-jacents des Api ou des modèles, mais le plus vous le faites, plus vous risquez de ne pas attraper une question de l'intégration. Une approche consiste à équilibrer les choses avec un petit nombre d'essais à la cheminée, et un plus grand nombre de tests entre deux couches seulement.