<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>8th Light Blog: BOC</title>
    <link>http://blog.8thlight.com/articles/2006/11/13/boc</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>In the minds of the craftsmen...</description>
    <item>
      <title>BOC</title>
      <description>&lt;div style="color: grey; font-family: courier; border: 1px solid black; margin-bottom: 10px; padding: 5px;"&gt;
BOC (Build Operate Check) n. : The typical flow of an automated test*
&lt;/div&gt;

&lt;p&gt;BOC is a testing pattern that Unclebob briefly mentioned on fitnesse.org shortly after it was published.  It describes the typical steps taken in an automated test.  &lt;/p&gt;

&lt;p&gt;Experienced test writer use BOC whether they know it or not.  For new-commers to automated testing, BOC is lesson #1.  &lt;/p&gt;

&lt;p&gt;If you think about it, BOC is very logical.  Every test is testing something; some Operation that the system under test (SUT) performs.  That&amp;#8217;s where the Operate step comes from.&lt;/p&gt;

&lt;p&gt;In almost all cases, you can&amp;#8217;t just invoke the operation.  The automated test Builds a testable environment first.  Maybe data needs to be put in a database, or a service layer needs to be started.  Either way, the Build step comes first. &lt;/p&gt;

&lt;p&gt;After invoking the Operation, a test needs to Check that it behaved as expected.  Clearly, the Check step has to come last.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Example:&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Consider a test for the Withdraw feature of an ATM machine.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Build:&lt;/em&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;You can&amp;#8217;t withdraw money from an account unless there&amp;#8217;s money in it.  For the build step, add $500.00 to account 123.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;em&gt;Operate:&lt;/em&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Perform a withdraw of $250.00 from account 123.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;em&gt;Check:&lt;/em&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Check that the balance of account 123 is $250.00.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Next time you&amp;#8217;re writing an automated test, think about it.  More likely than not, you&amp;#8217;re using BOC.&lt;/p&gt;</description>
      <pubDate>Mon, 13 Nov 2006 03:54:00 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:1d8bf5be-6f43-4d66-86c6-41ac19902909</guid>
      <author>Micah</author>
      <link>http://blog.8thlight.com/articles/2006/11/13/boc</link>
      <category>Testing</category>
      <category>Micah</category>
    </item>
    <item>
      <title>"BOC" by David Chelimsky</title>
      <description>&lt;p&gt;BDD is based on a similar triad - basically the same, but with different names: Given, When, Then. The nice thing about that is that customers and developers can talk about it and it means the same thing:&lt;/p&gt;

&lt;p&gt;Given an account with 500 bucks
When you withdraw 250
Then there should still be 250&lt;/p&gt;

&lt;p&gt;It&amp;#8217;s almost exactly the same, just possibly more customer friendly lingo.&lt;/p&gt;</description>
      <pubDate>Fri, 12 Jan 2007 05:03:20 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:843da52e-dea0-4d82-b95e-e2f416876c53</guid>
      <link>http://blog.8thlight.com/articles/2006/11/13/boc#comment-9</link>
    </item>
  </channel>
</rss>
