Proving Traits

"A play there is, my lord, some ten words long,
Which is as ‘ brief ’ as I have known a play.
But by ten words, my lord, it is too long"
-- Shakespeare, Midsummer Night's Dream

Act V, Scene I, Lines 61-63

Martin Heidegger in his paper, The Origin of the Work of Art, gives us three different ways of defining thingness.

1. bearer of traits and properties
2. sense perceptions
3. formed stuff

Traits is an interesting term in computer science, it is a collection of behaviors and their implementation which can be used to extend an object.  Most languages do not directly support the creation of stand-alone traits but traits are the essence of what makes up a programs value.

I am going to make a very bold statement here, I am going to say that BDD (Behavior Driven Development) is really about proving the traits of software.  Using the definition of traits given above we see that a trait is a collection of behaviors and how they have been implemented.  This sounds a lot like what we are proving out when we do BDD.

In BDD what are we doing?  We are proving that behavior X as it is implemented by code S does the following when given state G with stimulus W yielding state T.  In other words we are showing Given the following conditions, When we do the following against X in this Source code, Then the following result will occur.  This sounds a lot like proving the traits of the software to me.

"Words, words, words."

-- Shakespeare, Hamlet

Act II, Scene II, Line 193

Let us look at a example.

In the example above we see that a Starfleet Captain needs to be able to communicate with the FizzBuzzons and thus needs to have a translator.

She is given the following C# source code to preform the needed behavior of translating.

        public string Translate(int value)

        {

            var result = string.Empty;

 

            if (value % 3 == 0) result += "Fizz";

            if (value % 5 == 0) result += "Buzz";

 

            return string.IsNullOrEmpty(result) ? value.ToString() : result;

        }

To prove to her that it works the engineers and communication specialist came up with the following specifications listing what happens in a Given state When the an input value is translated Then the value will have a certain output.

Scenario: 2 must translate to the string 2

 Given a FizzBuzzer

 And the value of '2'

 When translate is invoked

 Then the result should be '2'

 

Scenario: 3 must translate to the string Fizz

 Given a FizzBuzzer

 And the value of '3'

 When translate is invoked

 Then the result should be 'Fizz'

 

Scenario: 5 must translate to the string Buzz

 Given a FizzBuzzer

 And the value of '5'

 When translate is invoked

 Then the result should be 'Buzz'

 

Scenario: 15 must translate to the string FizzBuzz

 Given a FizzBuzzer

 And the value of '15'

 When translate is invoked

 Then the result should be 'FizzBuzz'

By testing around these specifications we can prove to our captain that the translator does hold the desired traits.

Does this slight different definition around BDD change anything?  No, but I hope it does widen the thought around it.

"If we shadows have offended
Think but this, and all is mended:
That you have but slumbered here
While these visions did appear."

-- Shakespeare, Midsummer Night's Dream

Act V, Scene I, Lines 413-416