A user was asking the following on the Agile Modeling list:
What experience does anyone have about standards for stories written for
non-UI components? I’m working with a proxy PO who feels the standard story
format (As a <user> I want to <activity> so that <purpose>) simply won’t
work for something that doesn’t have a user interface. Imagine, for this
example, a project that has the sole purpose of encrypting data without any
For my needs, I often apply the principles behind the concepts, if not always the exact template of a suggested practice. Take for example, the use of my favorite tool, Cucumber, to write Acceptance Tests. Typically, cukes are written from the user point of view in classic “Given – When – Then.” But sometimes I like to use the cucumber style for testing APIs that I am building.
Here is one example at the Cucumber level (with the companion RSpec shown below):
Feature: Version 2.0: As we parse PDFs, we need to be able to collect a list of fonts as a way to help discern the structure of the parsed document based on heading levels, density of upper case text, and what not. Scenario: Parsing a simple document Given a sample set of text |reference|points|value| |R9| 10| Patient: FRANKLIN, BENJAMIN| |R9| 10| CHIEF COMPLAINT:| When i parse the text And provide a set of base fonts |ref |basefont| | R9 | Helvetica-Bold| |R10 | Helvetica | Then I should have the following font stats |reference|points|upper_cnt|lower_cnt|percent| |R9 | 10 | 4 | 1 | 83 | And the following font names |reference |points|basefont| | R9 | 10 |Helvetica-Bold| | R10 | 10 |Helvetica | Scenario Outline: Parsing a simple document When collecting a set of text , , Then I should have and word counts and Uppercase stats # Note: the counts are cumulative Examples: |reference|points|value|upper_cnt|lower_cnt|percent| | R9| 10| "Patient: FRANKLIN, BENJAMIN" | 2 | 1 | 66 | | R9| 10| "CHIEF COMPLAINT:" | 4 | 1 | 83 | | R9| 10| "PRESCRIPTIONS" | 5 | 1 | 89 | |R10| 9| "Motrin 600mg, Thirty (30), Take one q.i.d. as needed for pain, Note: Take with food, Refills: None."| 0 | 13 | 0 | |R10| 9| "(Discount Medication) < Michael L. Panera, PA-C 7/13/2010 17:40>"| 0 | 17 | 0 |
And here’s another one:
Feature: Extract meaningful data from Discharge Message Scenario: Extract headings Given a discharge message When the message is parsed Then I should see meaningful information, structured as headings and paragraphs And I can get formatted values for HTML display Scenario: Extract headings from second message Given a second discharge message When the message is parsed Then I can get formatted values for HTML display
But wait! There is more!
At the “Unit Test” level, RSpec’s can be made rather “english friendly” yet still be all about the underlying API as this diagram and snippet show:
describe PdfParser do describe PdfParser::FontCollector do before(:all) do PdfParser::FontCollector.clear_all() ... end context "initialize" do it "should reject missing font reference" do ... end it "should reject missing points" do ... end it "should reject missing value" do ... end it "should accept valid inputs" do ... end it "should start off with simple stats" do ... end it "should recognize reference+size is unique" do ... end end context "clear" do it "should clear the font list" do ... end end
Hi Jon, excellent!
And as usually is not a problem with the tool, instead is a problem with the naming.
Always you can “tune” your tool to get the “naming” you need in each occasion.
Ok, ok, maybe with Ruby is more easy 😉
Regards from Spain 🙂