Geek Answers Handbook

BDD, what feature?

I am just starting with BDD and I am trying to create a small application, so I see that it works in a real environment, but I have problems resolving the issue of what should be a function. I'm building a tiny shop.

I decided that “Compare Products” would be a feature, and “User can check how a guest” would be one, but for this I need to list products first.

My question is: should there be a list of products?

Thanks!

+7
bdd
source share
7 answers

This should probably be a function, but try to formulate it from the point of view of the user. What does this product list offer?

  • The user should be able to get an overview of the products on offer.
  • The user should be able to order and reorder products by name, price, availability.
+4
source share

It is very difficult to start doing BDD. The only thing that helps you feel confident in your abilities and the whole approach is to write test scripts and code that executes them. I would advise you not to complicate a complicated and confusing situation. Select any task that you need to implement, open an empty text file and try to explain the behavior using simple sentences. Each sentence must begin with one of three keywords: given,, when , and then . Using your favorite BDD environment, write code that will analyze these sentences and stimulate the application to enter the initial state (set), execute some commands (when) and approve the transition state (then). Application code can start with simple mocks. Replace these bullying phrases with gradual code and grow your application with a higher level of confidence and quality.

+2
source share

User history is a feature. Something that can be expressed in the format:

  • Like a role
  • I would like to do something
  • To goal

eg.

  • As user
  • I would like to be able to compare products

  • So that I can best choose a product that suits my needs

  • Like a guest

  • I would like to check my basket.
  • So that I can complete the purchase

Each function must be confirmed, of course, by a series of Given-When-Then scripts.

+1
source share

Basically you ask what a function is. Think about it, you have a story, the story describes the function that you (or other people) want for your application. Usually it has the form: As a user, I want to view a list of products. You can add notes to this story to make it clearer. But then a specific behavior arises (which you will ultimately test) - there are an infinite number of behaviors corresponding to this story (think about viewing products and many ways of presenting them). Your focus, in BDD, is to find the behavior that suits your application (I use the application, not the user, because sometimes you have to decide for the user) - talking to as many people as you can, trying to try and iterate it ended .

I like to go from top to bottom - always try to focus on behavior - to be more specific when you walk. If you think about it, given the behavior (which means a set of tests), there are an infinite number of implementations. Therefore, the focus of BDD is to truly understand behavior by experimenting and talking - there is always a degree of freedom.

+1
source share

More important would be to figure out what the user wants to do with the product list? this feature will provide something valuable to the user. so in your case it will be

  • Select a product to view from the product list
  • Select x products to compare from the product list.
  • Other
+1
source share

I would classify a function as a minimum useful set of stories that provide some consistent (business) value.

for a BDD structure see http://kernowcode.wordpress.com

+1
source share

To determine if a requirement is an explicit characteristic / history of the user, you can use task-based design guidelines and documentation (e.g. http://www.sprez.com/articles/task-documentation-design.html ). Such concepts confirm that the user of the system wants to achieve a certain result. Usually, to know something (for example, what products are available), this is just a step in the process of buying / selling / building / etc. A good starting point in BDD is to write down the topics you will use in the chapters of your user guide. These themes are usually the features that you intend to provide in your software solution. A good foundation supporting this approach in specification is Concordion ( http://concordion.org ). Please see the description of the "acceptance tests in plain English" ( http://gojko.net/2009/09/01/acceptance-testing-in-plain-english-with-concordion-net/ ).

0
source share

More articles:


All Articles