Another point to consider in BDD for EIS is the question of Abstraction during testing. The same way we expect to describe requirements through BPM, we probably would like to write tests not using examples, but parameters instead. I mean, instead of declaring things like
Given that a client buys a jumper
And I have an inventory of three jumpers
When the client returns a jumper
Then I will have four jumpers in inventory
I would have something like
Given that a client buys a given product
When the client returns this product
Then I will add this returned product to my inventory
Since tests must deal with examples, parameters must be marked for parsing and when we run tests we must supply these parameters. Many automated tests tools already do that.
I think parameterizing is a must in the case of EIS development and customization. Think in terms of an ERP and its different adopters, probably they will demand different test sets during customization or even system evaluation. Actually, during deployment, you are going to import a lot of legacy data, thus it is interesting to use this data for testing.
See? Parameterization is a must for Agile EIS testing.
A blog devoted to the discussion of practical techniques for developing Enterprise Information Systems (EIS).
Ideas on Enterprise Information Systems Development
This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.
Thursday, September 9, 2010
Subscribe to:
Post Comments (Atom)
You can use examples as parameters :)
ReplyDeleteCucumber, Lettuce, Freshen and other tool support _Scenario Outlines_ with _Examples_. You can do something like:
Scenario Outline: A client buys a product
Given a client buys a <product>
And I have an inventory of <initial_number> <product>
When the client returns this product
Then my inventory has <final_number> <product>
Examples:
| product | number | final_number |
| jumper | 3 | 4 |
| pencil | 2 | 3 |
| computer | 0 | 1 |
And you avoid duplication of scenarios! Take a look here: http://wiki.github.com/aslakhellesoy/cucumber/scenario-outlines
Is this what you are talking about or I have misunderstood it!?
Cheers,
Hugo.
Yes, it is exactly this! Thanks for the example!
ReplyDeleteLike to write tests not using examples, but parameters instead. I mean, instead of declaring things like.Mark R. Smith
ReplyDeleteThe example above uses parameters.
ReplyDeleteThank you for posting such a great article! I found your website perfect for my needs
ReplyDeleteclick to more details