Jul 22 2010
Driving CRUD screens with BDD
There is a discussion on the UK agile testing mailing list on driving the development of an administrative application with BDD. It illustrates a problem that many teams have, so I’ll post my response here as well.
Although we have a long way to go things are going OK at the moment and we feel it is bringing some real focus to the development process. However a lot of the early stories are largely admin type CRUD – for
example functionaility to set up user defined entities and their user defined properties within the system and to provide a mechanism for relating these entities to each other
…
Does anyone have any advice about how to write tests for this sort of stuff or any experiences in starting out with BDD they can share.
CRUD is not a user story, it’s a screen. It’s not a business function, but implementation detail. Why do the business users need a particular CRUD screen? (I know it sounds as a stupid rhetorical question, but I’m serious) What does it allow them to do?
Often you don’t need to implement an entire CRUD screen and deliver them one by one. Sometimes there is value in releasing two screens that allow you to set a subset of properties but together they bring value. You can then automate these tests through the UI and use the CRUD screens, but that will be hidden in the automation layer. Say for example that we have a risk report that lists users and their card numbers:
Scenario: Only regular customers with a specific risk category and
card type show up in risk reports
Given the following users
|name| type| card type| card number| risk category|
|Mike |VIP | Mastercard |53111 11111 11111 1111|X|
|Tom |VIP| Visa |41111 11111 11111 1111|Y|
John |Regular |Mastercard |51111 11111 11111 1111|X|
|Steve |Regular |Mastercard |52111 11111 11111 1111|Y|
Then the risk report for Mastercard and category X contains the following data
|John | 51111 11111 11111 1111|
This could, for example, invoke the user CRUD to save a user name, type and risk category and a completely different CRUD to save card details for that user. Any other information that would go on that CRUD (addresses, card expiry dates etc) aren’t part of this story or criteria because they are not important for this particular report.
Start with the outputs, the reports that the system produces, instead of data entry operations. this ensures that you have the data you need to produce the reports at the end, and that you don’t have superfluous data that nobody really cares about. if you don’t do that, the resulting data schemas are often overcomplicated and contain many things that simply aren’t used at the end at all.
 |
 |
