User Stories To Code

Question

Suppose I have a bunch of User Stories ( as a result of the planing Session I went through with my team ). I don't have any code in the application yet and going to start with my 'A' or highest Priority Stories/Epics

Say for example

"As A User I should be able to Search for more users so that I can add more friends on the website"

So how should the team go about coding the application while doing TDD.

• Team starts with creating Unit tests ie .that take care of Creating models

• Then everybody takes a story and starts writing functional tests to create my controllers / Views ( So Should they be doing integration testing while writing functional tests )

• Then do the integration tests

I am actually confused how the integration tests fit in.if all the integration tests work ( ie all the functional, units tests should anyway pass )

So, If the application is just starting ( ie no Code has been written yet ). What is the process people usually take for TDD/BDD when they pick up a Story and start, for implementing a application from scratch

Answer 1

First, break the story apart. You'll need:

1. A User object: What does it do? Create some tests to figure this out and write the code
2. A way to search users; maybe a SearchUserService? Again create tests and write the code
3. A way to connect users ...

Now, you have the model. Next, you do the same for the controllers. When they work, you start with the views.

Or, when you're a pro and have done this a thousand times already, you might be able to roll several steps at once.

But you must first chop the problem into digestible pieces.

Next for the integration tests. They will simulate what a user does. In the general case, you need to write a set of unit tests (they are just called integration tests but you should also be able to run them automatically). These tests need to talk to the web app just like the user does, so you need a simulated web browser, etc.

You can try httpunit or env.js for this.

Answer 2

This is where we usually start off with a Sprint 0 and in this spring is where we'll have what XP call's a Spike Session (or a Throw away code session). In this session is where you can begin prototyping.

In your session write a few user acceptance tests (preferrably in the BDD format) and then start writing a test first to match one of your UAT's.

For example:

Given a search is requested where user's name is "testUser" 1 result should be returned.

With this you now have a goal for your first test, which you write, then begin writing code to make that test pass. As you go forward you should begin to see how the app should be put together to complete the story.

Then I would begin in the next sprint building stories/task's to complete the feature as needed based upon what you discovered in the sprint 0.

Answer 3

Very good question! The TDD/BDD way would suggest you take the user stories and write validation points (read high level tests). They use GWT (Given/When/Then) speak as follows.

"As A User I should be able to Search for more users so that I can add more friends on the website"

given the website URL
when the site loads
then a search field should be visible/accessible.

This is your first piece of feedback and first opportuniuty to iterate with the product owner. Ask questions like where should the search bar go? Should it auto complete? Etc. Next you assign "behavior to the UI objects. These also have validation points.

This would define the behavior of the search button:

given a go button next to the search field
when then button is clicked 
then a search should be performed

this would describe the logic of your search:

given a search term "John" and a user set including "John, Joan, Jim, Steve"
when a search is performed
then the results should contain "John" an "Joan"

The first validation point would describe the behavior of linking the controller search button to an arbitrary model implementing the search algorithm. The second validation point describes the search algorithm itself. The advantage is that these pieces are defined independently and can be designed in parallel. It also gives you a nice API and small easily to plan features to iterate on. It also gives you the ability to iterate/refine on any piece of the puzzle without affecting the rest of the pie.

Update I also want to mention that what I refer to as validation points can loosely be associated with UATs or User Acceptance Tests. Don't get hung up on the terms because they're irrelevant. Focus on the idea behind them. You need to take the user story and break it down into specs. (can be done in one or many passes using either UATs or validation points or both or magic beans just make sure you break them down.) If what you have broken your user stories into can be written in a tool like FitNesse, JUnit, or RSpec then use one of these tools, other wise you need either further conversation (Are your user stories too vague?) or another pass over what you have to break down further (UATs to validation points). Don't obsess over the tools and feel like you need to automate everything from the beginning. Leave Selenium alone until you get the manual process down. Eventually you want specs that can be written in programmatic test-like form at this time you should be able to use something as simple as JUnit to start coding. When you get better/fancier you can pick up EasyB or RSpec story runner and other things.

Answer 4

If you're doing TDD, you start with a test that shows that the system does not perform the required behaviour described by the user story. When that is failing in the way you expect, with useful diagnostics, you then start implementing the behaviour by adding or modifying classes, working unit-test first.

So, in TDD you write integration tests before you write unit tests.

To bootstrap the whole process, one usually writes a "walking skeleton": a system that performs the thinnest slice of realistic functionality possible. The walking skeleton let's one build up the integration test infrastructure against simple functionality.

The rest of the project then fleshes out that skeleton.

Answer 5

"I am actually confused how the integration tests fit in.if all the integration tests work ( ie all the functional, units tests should anyway pass )"

It depends. Sure, it's possible to write integration tests in such a way that all unit and functional tests pass. It's just much more difficult.

Imagine that you have 3 models, 3 controllers and 3 views. Imagine that all are super simple with no conditions or loops and have one method each.

You can now (unit) test each one of these for a total of 9 assertions and have full coverage. You can throw in an integration test to make sure all these things work well together.

If instead you skip units/functionals and needed to have full coverage, you're going to need 27 assertions (3 x 3 x 3).

In practice things are more complicated of course. You'll need a much larger amount of integration tests to get to the same level of coverage.

Also, if you practice TDD/BDD, more often than not will wind up with lots of unit tests anyway. The integration test is there to make sure all these pieces fit well together and do what the customer wants. The pieces themselves have been tested individually by the unit tests.