Professional Test-Driven Development with C#: Developing Real World Applications with TDD

7

Implementing the First User Story

WHAT'S IN THIS CHAPTER?

• How to decompose user stories into features
• How to develop by writing unit tests before you write business code
• What a business-driven development (BDD) naming style looks like
• How BDD can help you write tests that are clear and easy to understand
• How unit tests enable you to refactor code without fear of breaking features or functionality
• Why triangulation of tests is important to ensure the quality of your code

Now that the overall scope and high-level design for the office supply inventory management (OSIM) application have been defined, it's time to start constructing the application. As outlined in my agile-based methodology, construction starts with the business owner choosing the user stories or features to be developed in the first iteration. With some guidance from the PM and the application architect, the business owners have decided on the following user story:

A user should be able to add a new type of item to the application.

This is a logical place to start, because this is an inventory management system. To manage inventory (and work with the features that would be provided by the other user stories), the users need to have a list of items in inventory.

To start, you need to break the larger user story into smaller features. Features should be small, simple, isolated, and testable. For the current user story, I've come up with this list of features:

• An item type entity and a persistence layer that ...