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.

Thursday, September 9, 2010

Abstraction and Test By Example in the EIS Case

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.


  1. You can use examples as parameters :)
    Cucumber, 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>

    | product | number | final_number |
    | jumper | 3 | 4 |
    | pencil | 2 | 3 |
    | computer | 0 | 1 |

    And you avoid duplication of scenarios! Take a look here:

    Is this what you are talking about or I have misunderstood it!?


  2. Yes, it is exactly this! Thanks for the example!

  3. Like to write tests not using examples, but parameters instead. I mean, instead of declaring things like.Mark R. Smith

  4. Thank you for posting such a great article! I found your website perfect for my needs
    click to more details