<HTML>
<HEAD><!-- Template generated by Exclaimer Mail Disclaimers on 05:55:10 Friday, 6 June 2014 -->
<STYLE type=text/css>P.ae431132-9d17-4a38-b6b5-634369783623 {
        MARGIN: 0cm 0cm 0pt
}
LI.ae431132-9d17-4a38-b6b5-634369783623 {
        MARGIN: 0cm 0cm 0pt
}
DIV.ae431132-9d17-4a38-b6b5-634369783623 {
        MARGIN: 0cm 0cm 0pt
}
TABLE.ae431132-9d17-4a38-b6b5-634369783623Table {
        MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
        page: Section1
}
</STYLE>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</HEAD>

<BODY style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<P class=ae431132-9d17-4a38-b6b5-634369783623>
<div id="bloop_customfont">Hey all,</div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont">Sorry for the length of reply - but I want to provide as much information as possible about this topic. </div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont">Instead of enumerating pros and cons, I want to give a bit of context first (about what “feature stories” actually are), and then respond to some common misconceptions about them. This way, the pros/cons of Behat are a bit more substantiated. </div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont"><b>Would Behat replace PHPUnit</b>?</div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont">No - they’re completely different. We’d still use phpunit for unit testing because it’s way better at xunit-like assertions. We’d use behat instead for functional testing - making sure that features work against a production API.</div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont"><b>Who’s using Behat and is it suitable for us?</b></div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont">From what I’ve heard, we’re using it for some projects at Rackspace and possibly some OpenStack projects - but I need to double check that. I’ve reached out to some folks about their experiences with it - so I’ll post the findings
 when I hear back.</div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_customfont"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><b>What are BDD feature stories?</b></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><b><br />
</b></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">Here’s a link to a fantastic article which explains the benefits of BDD feature stories: <a href="http://dannorth.net/whats-in-a-story/">http://dannorth.net/whats-in-a-story/</a></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">tl;dr:</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">
<div id="bloop_sign_1402068071466034944" class="bloop_sign">BDD takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone
 knows what’s going on. To do this, we need a way to describe the requirement such that everyone – end-user, contributor, manager, technical lead (in short, anyone interested in using our SDK in their business) – have a common understanding of the scope of
 the work. You are showing them, in human-readable language, the features of the SDK and what it offers them. The result is that everyone — regardless of proficiency, skill level and familiarity with the codebase — is on the same level of understanding. From
 this they can agree a common definition of “done”, and we escape the dual gumption traps of “that’s not what I asked for” or “I forgot to tell you about this other thing”.</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">This, then, is the role of a Story. It is a description of a requirement and a set of criteria by which we all agree that it is “done”. It helps us understand and satisfy customer use-cases in a well
 expressed and clear way. It also helps us track project progress by having well-established acceptance criteria for feature sets. </div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><b>3 misconceptions about BDD</b></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">(Inspired by <a href="http://www.thoughtworks.com/insights/blog/3-misconceptions-about-bdd">http://www.thoughtworks.com/insights/blog/3-misconceptions-about-bdd</a>)</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><b>1. End-users don’t care about this! They want code</b></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">This is actually a completely misdirected point. The purpose of behat is not to serve as a public-facing repository of sample code. Its actual purpose is twofold: to serve as a functional test suite
 (i.e. make sure our SDK works against an API), and secondly to serve as a communication device - to codify features in a human-readable way.</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">It’s the role of documentation to explain the concepts of the SDK with detailed code samples. Another good idea is to provide a “samples” folder that contains standalone scripts for common use-cases
 - this is what we offer for our current SDK, and users appreciate it. Both of these will allow developers to copy and paste working code for their requirements.</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><b>2. Contributors don’t want to write these specifications!</b></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">My response is this: how can you implement a piece of functionality if you have no idea what it’s supposed to do? You’re not communicating the scope of the feature, you’re not defining the criteria
 that makes the feature “done” - you’re just slinging code. Without feature stories, if somebody has a major problem with an approach you’re taking in your development of a feature, you’ll only find out afterwards in Gerrit. You’d end up wasting hours on stuff
 that does not deliver the feature as expected - it’s a wasteful and inefficient example of miscommunication that could easily be avoided.</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">If you write the acceptance criteria beforehand - you know exactly what you have to contribute. Everybody knows when the feature will be “done” because you’ve settled all the defined customer use-cases.
 Writing feature stories is all about collaboration and communication.</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><b>3. You can achieve the same with normal code!</b></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">Again, this is a misdirected point because comparing them is like comparing apples and oranges - they’re completely different things. </div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><i>Behat is for communication. </i>The whole reason for using the Gherkin DSL is for its readability. Its aim is to improve communication and help people understand features.  PHP code does not offer
 this - you’d end up trying to communicate features to people who are not proficient with our codebase, who may not be strong coders, and who might not even know PHP. We can’t assume that people want to traverse a labyrinth of code just to understand how a
 feature works.</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><i>Behat is for defining end-user expectations. </i>Writing normal code doesn’t offer us a way to “test” functionality. With Behat we’re explicitly testing expectations: does this scenario return the
 right thing? Does it return this value? What about if I was a different user with different data? You’re testing scenarios. How easy would that be using normal PHP code? You’d have hundreds of lines and probably lots of messy exceptions. In short, it's messy
 and massively inefficient. Behat allows us to avoid this clumsiness and duplication by centralizing this type of expectation checking.</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><b>Ugh, another dependency. What happens if we switch to another BDD framework?</b></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><b><br />
</b></div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">Absolutely nothing. The beauty of the Gherkin syntax is that it’s framework independent. This means we could even take the Feature files from another non-PHP project, such as an OpenStack one, and
 it’d be fine. We’d have to re-configure our context classes (the things which links human-readable DSL into SDK calls), but that’d be it. It’s completely interoperable :)</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign"><br />
</div>
<div id="bloop_sign_1402068071466034944" class="bloop_sign">Jamie </div>
</div>
<div id="bloop_sign_1402073632608659968" class="bloop_sign"></div>
<br />
<p style=color:#000;>On June 6, 2014 at 12:22:54 PM, Choi, Sam (<a href="mailto:sam.choi@hp.com">sam.choi@hp.com</a>) wrote:</p>
<blockquote type="cite" class="clean_bq"><span>
<div lang="EN-US" link="blue" vlink="purple" xml:lang="EN-US">
<div></div>
<div><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<title></title>
<div class="WordSection1">
<p class="MsoNormal">Hello all,</p>
<p class="MsoNormal">During our most recent php sdk team meeting, a suggestion to use the PHP framework Behat (<a href="http://behat.org/">http://behat.org/</a>) was brought up. I’d like to begin a discussion around the pros/cons of using Behat to create tests.
 For those not familiar with the php sdk or Behat, we are currently using PHPUnit for all of our tests and are considering Behat for writing human-readable stories that can potentially generate tests that can be run against the sdk.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b>A couple general questions for all devs</b></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l2 level1 lfo1"><!--[if !supportLists]--><span style=mso-list:Ignore>-<span style="font:7.0pt "Times New Roman"">       </span></span><!--[endif]--> Is a similar framework being used for any OpenStack
 CLI/SDK project? I’d love to see an example.</p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l2 level1 lfo1"><!--[if !supportLists]--><span style=mso-list:Ignore>-<span style="font:7.0pt "Times New Roman"">       </span></span><!--[endif]--> What kind of pros/cons have you all seen when
 using Behat or similar frameworks for testing?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b>Jamie</b></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l2 level1 lfo1"><!--[if !supportLists]--><span style=mso-list:Ignore>-<span style="font:7.0pt "Times New Roman"">       </span></span><!--[endif]--> Would the suggested Behat framework be intended
 to supplement our existing PHPUnit tests? In effect, giving us a set of Behat tests and PHPUnit tests. Or was the suggestion to have all tests rely on the Behat framework?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">After reviewing Behat and some related technologies, I do have a few concerns at the moment. Any thoughts of the concerns would be appreciated.</p>
<p class="MsoNormal"> </p>
<p class="MsoListParagraph" style="margin-left:27.0pt;text-indent:-.25in;mso-list:l2 level1 lfo1;vertical-align:middle">
<!--[if !supportLists]--><span style=font-size:12.0pt><span style=mso-list:Ignore>-<span style="font:7.0pt "Times New Roman"">       </span></span></span><!--[endif]--> We are introducing another dependency for the PHP SDK. What happens if there is a reason
 for us to switch to another BDD framework or ditch it to go back to PHPUnit? It seems like we would likely be faced with significant test refactoring.</p>
<p class="MsoListParagraph" style="margin-left:27.0pt;text-indent:-.25in;mso-list:l2 level1 lfo1;vertical-align:middle">
<!--[if !supportLists]--><span style=mso-list:Ignore>-<span style="font:7.0pt "Times New Roman"">       </span></span><!--[endif]--> Contributors will have to be proficient with Behat/BDD in order to write tests for the PHP SDK. This adds to what may already
 be a steep learning curve for a new contributor who has to learn our code base, Guzzle for the transport layer, how to use various/develop various cloud services etc.</p>
<p class="MsoListParagraph" style="margin-left:27.0pt;text-indent:-.25in;mso-list:l2 level1 lfo1;vertical-align:middle">
<!--[if !supportLists]--><span style=mso-list:Ignore>-<span style="font:7.0pt "Times New Roman"">       </span></span><!--[endif]--> For more complicated tests, writing out features, scenarios, step definitions, and testing logic would almost certainly take
 longer than writing a traditional test in pure PHP.</p>
<p class="MsoListParagraph" style=vertical-align:middle> </p>
<p class="MsoNormal" style=vertical-align:middle>Thanks,</p>
<p class="MsoNormal">--</p>
<p class="MsoNormal"><b>Sam Choi</b></p>
<p class="MsoNormal">Hewlett-Packard Co.</p>
<p class="MsoNormal">HP Cloud Services</p>
<p class="MsoNormal">+1 650 316 1652 / Office</p>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</span></blockquote>
</P>
<P class=ae431132-9d17-4a38-b6b5-634369783623> </P>
<P class=ae431132-9d17-4a38-b6b5-634369783623>
<TABLE border=0 cellPadding=0 width=504>
  <TBODY>
  <TR>
    <TD style="WIDTH: 270px" class=LEFT_ALIGNED><span style='font-family:Verdana; font-size:small; '>Jamie Hannaford</span><BR /><span style='font-family:Verdana; font-size:x-small; '>Software Developer III - CH</span></TD>
    <TD style="WIDTH: 281px"><IMG alt="experience Fanatical Support" align=right src="cid:image82de36.JPG@ed487104.4589de93" width=159 height=17 /></TD></TR>
  <TR class=LEFT_ALIGNED>
    <TD colSpan=2><IMG alt=LINE src="cid:imagefb2f83.JPG@b0d74f29.4a9b1a75" width=504 height=4 /></TD></TR>
  <TR>
    <TD class=CONTACTINFO><span style='font-family:Calibri; '><table class=ae431132-9d17-4a38-b6b5-634369783623Table><tr><td><span style='font-family:Verdana; font-size:x-small; '>Tel: </span></td><td><span style='font-family:Verdana; font-size:x-small; '>+41434303908</span></td></tr><tr><td><span style='font-family:Verdana; font-size:x-small; '>Mob: </span></td><td><span style='font-family:Verdana; font-size:x-small; '>+41791009767</span></td></tr></table></span></TD>
    <TD class=RIGHT_ALIGNED><IMG alt=Rackspace src="cid:imagee4c271.JPG@ea10b7cb.46a96632" width=280 height=60 /></TD></TR>
  <TR class=LEFT_ALIGNED>
    <TD class=CONTACTINFO colSpan=2><IMG src="cid:image5fae94.JPG@2bb82a71.4bb610b4" width=504 height=3 /></TD></TR></TBODY></TABLE></P>
<P class=ae431132-9d17-4a38-b6b5-634369783623> </P>
<P class=ae431132-9d17-4a38-b6b5-634369783623></P><span style="font-size: 11px;">Rackspace International GmbH a company registered in the Canton of Zurich, Switzerland (company identification number CH-020.4.047.077-1) whose registered office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace International GmbH privacy policy can be viewed at www.rackspace.co.uk/legal/swiss-privacy-policy<br>-<br>Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Suite 3, Level 7, 210 George Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php<br>-<span style="font-size: 11px;"></span><br>Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United States of America</span><br><span style="font-size: 11px;">Rackspace US, Inc privacy policy can be viewed at www.rackspace.com/information/legal/privacystatement</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ.</span><br><span style="font-size: 11px;">Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Benelux B.V. is a company registered in the Netherlands (company KvK nummer 34276327) whose registered office is at Teleportboulevard 110, 1043 EJ Amsterdam.</span><br><span style="font-size: 11px;">Rackspace Benelux B.V privacy policy can be viewed at www.rackspace.nl/juridisch/privacy-policy</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Asia Limited is a company registered in Hong Kong (Company no: 1211294) whose registered office is at 9/F, Cambridge House, Taikoo Place, 979 King's Road, Quarry Bay, Hong Kong.</span><br><span style="font-size: 11px;">Rackspace Asia Limited privacy policy can be viewed at www.rackspace.com.hk/company/legal-privacy-statement.php</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">This e-mail message (including any attachments or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@rackspace.com and delete the original message. Your cooperation is appreciated.</span></BODY>
</HTML>