2010-07-13 16 views
7

Je commence juste avec BDD et j'essaye de construire une petite application, ainsi je peux la voir fonctionner dans un environnement réel, mais j'ai du mal à décider quelle devrait être une fonctionnalité. Je construis un petit magasin.BDD, quelle est une fonctionnalité?

J'ai décidé que "comparer les produits" sera une fonctionnalité et "l'utilisateur peut commander en tant qu'invité" sera une, mais pour arriver à cela, je dois d'abord énumérer les produits.

Ma question est la suivante: devrait-il y avoir une liste de produits?

Merci!

Répondre

4

Cela devrait probablement être une fonctionnalité, mais essayez de la formuler du point de vue de l'utilisateur. Que lui offre cette liste de produits?

  • L'utilisateur doit être en mesure d'obtenir un aperçu des produits offerts
  • L'utilisateur doit pouvoir commander et réordonner produits sur le nom, le prix, la disponibilité.
2

Il est assez difficile de commencer à faire BDD. La seule chose qui aide à se sentir confiant dans vos capacités et l'approche globale est d'écrire des scénarios de test et le code qui les exécute. Je vous suggère de ne pas rendre la situation déjà complexe et confuse plus difficile. Choisissez n'importe quelle tâche que vous devez implémenter, ouvrez un fichier texte vide et essayez d'expliquer en utilisant des phrases simples le comportement. Chaque phrase doit commencer par l'un des trois mots-clés: donné, lorsque et puis. En utilisant votre cadre BDD favori, écrivez le code qui analysera ces phrases et stimulera l'application pour entrer dans l'état de départ (donné), exécutera quelques commandes (quand) et affirmera l'état de transition (alors). Le code d'application peut commencer à partir de simples simulacres. Remplacez progressivement ces modèles par du code construit progressivement et développez votre application avec des niveaux de confiance et de qualité plus élevés.

1

L'histoire de l'utilisateur est une caractéristique. Quelque chose qui peut être exprimé sous forme de:

  • Comme rôle
  • Je voudrais faire quelque chose
  • Alors que but

Par ex

  • En tant qu'utilisateur
  • Je voudrais être en mesure de comparer les produits
  • Alors que je peux choisir un produit répondant à mes besoins dans une meilleure façon

  • Invitée

  • I voudrais vérifier mon panier
  • Pour que je puisse compléter l'achat

Chaque caractéristique doit être confirmée par une série de scénarios donnés-quand-alors, bien sûr.

1

Vous demandez essentiellement ce qu'est une fonctionnalité. Pensez-y, vous avez une histoire, une histoire décrit une fonctionnalité que vous (ou d'autres personnes impliquées) voulez pour votre application. Habituellement, il a la forme de: En tant qu'utilisateur, je veux voir la liste des produits. Vous pouvez ajouter des notes à cette histoire, afin de le rendre plus clair. Mais vient ensuite le comportement spécifique (que vous allez tester par la suite) - il y a un nombre infini de comportements qui se conforment à cette histoire (pensez à la vue des produits et aux nombreuses façons de les présenter). Dans BDD, votre objectif est de trouver le comportement dont votre application a besoin (j'utilise l'application et non l'utilisateur, car parfois vous devez décider pour l'utilisateur) - en parlant à autant de personnes que possible, en essayant des choses et en itérant c'est terminé. C'est comme aller de haut en bas - en essayant toujours de se concentrer sur le comportement - être plus précis au fur et à mesure. Si vous y réfléchissez, étant donné un comportement (c'est-à-dire un ensemble de tests), il existe un nombre infini d'implémentations. C'est pourquoi le but de BDD est de vraiment comprendre le comportement en expérimentant et en parlant - il y a toujours un degré de liberté.

1

Plus important serait de savoir ce que l'utilisateur veut faire avec la liste des produits? la fonctionnalité fournirait quelque chose de précieux pour l'utilisateur. donc dans votre cas, il serait

  • Choisissez un produit pour une liste de produits
  • Choisissez des produits de x à comparer à partir d'une liste des produits
  • Autres
0

Pour déterminer, Si une exigence est une fonctionnalité explicite/une histoire d'utilisateur, vous pouvez utiliser les directives de la conception/documentation basée sur les tâches (par exemple http://www.sprez.com/articles/task-documentation-design.html). De tels concepts reconnaissent qu'un utilisateur d'un système veut atteindre un résultat spécifique. Habituellement, savoir quelque chose (comme: quels produits sont disponibles) n'est qu'une étape dans le processus d'achat/vente/construction/etc. Un bon point de départ dans BDD est d'écrire les sujets que vous utiliseriez comme chapitres dans votre utilisateur Manuel. Ces sujets sont généralement les fonctionnalités que vous allez fournir dans votre solution logicielle. Un bon cadre qui prend en charge une telle approche de spécification par exemple est Concordion (http://concordion.org). S'il vous plaît jeter un oeil à la description de "tests d'acceptation en anglais ordinaire" (http://gojko.net/2009/09/01/acceptance-testing-in-plain-english-with-concordion-net/).