Trying Out Coulda

1 view
Skip to first unread message

Scott LaBounty

unread,
Oct 2, 2009, 4:43:43 PM10/2/09
to cou...@googlegroups.com
OK, I've never done much testing and I'm trying to learn. Given the following class in test.rb

<<
class MyTest
    def initialize(x, y)
        @x = x
        @y = y
    end

    def addThem
        @x + @y
    end

    def subtractThem
        @x - @y
    end

    def multiplyThem
        @x * @y
    end
end
>>

Here's some test code I wrote:

<<
require 'rubygems'
require 'coulda'
require 'test'
include Coulda
 
Feature "Test It" do
  in_order_to "demonstrate a simple test of test"
  as_a "coulda developer"
  i_want_to "provide a straight-forward scenario"
 
  def start_test
    @test = MyTest.new(2, 3)
  end
 
  Scenario "Test addThem" do
    Given "Test initialized with 2 and 3" do
      start_test
    end
 
    When "I addThem" do
      @test.addThem
    end
 
    Then "it should be 5" do
      assert(5)
    end

    Given "Test initialized with 2 and 3" do
      start_test
    end
 
    When "I subtractThem" do
      @test.subtractThem
    end
 
    Then "it should be -1" do
      assert(-1)
    end
  end

#  Scenario "Test subtractThem" do
#    Given "Test initialized with 2 and 3" do
#      start_test
#    end
#
#    When "I subtractThem" do
#      @test.subtractThem
#    end
#
#    Then "it should be -1" do
#      assert(-1)
#    end
#  end

end


>>

First should the tests I've written above be as I did them initially (the commented version) or how it ended up (with the two Given/When/Then sections in the same Scenario (completely misnamed, I know).

Anything else I should be doing/not doing?

I'm also working with Ramaze. Has anyone done anything with coulda/Ramaze?

Thanks for whatever help you can provide.
--
Scott
http://steamcode.blogspot.com/

Evan Light

unread,
Oct 2, 2009, 6:21:40 PM10/2/09
to cou...@googlegroups.com
Comments inline.



On 10/2/09 4:43 PM, Scott LaBounty wrote:
OK, I've never done much testing and I'm trying to learn. Given the following class in test.rb

<<
class MyTest
You probably want the following too:

attr_reader :x, :y, :x_min_y, :x_plus_y, :x_times_y


    def initialize(x, y)
        @x = x
        @y = y
    end

    def addThem
        @x + @y
    end

Maybe this should be

        def addThem
            @x_plus_y = @x + @y

        end

    def subtractThem
        @x - @y
    end

        See addThem.  You probably want to see this on @x_minus_y.


    def multiplyThem
        @x * @y
    end

        See addThem and subtractThem.

end
>>

Here's some test code I wrote:

<<
require 'rubygems'
require 'coulda'
require 'test'
include Coulda
 
Feature "Test It" do
  in_order_to "demonstrate a simple test of test"
  as_a "coulda developer"
  i_want_to "provide a straight-forward scenario"
 
  def start_test
    @test = MyTest.new(2, 3)
  end
 
  Scenario "Test addThem" do
    Given "Test initialized with 2 and 3" do
      start_test
    end
 
    When "I addThem" do
      @test.addThem
    end
 
    Then "it should be 5" do
      assert(5)

            You probably then want:

            assert_equal(5, @test.x_plus_y)


    end

    Given "Test initialized with 2 and 3" do
      start_test
    end
 
    When "I subtractThem" do
      @test.subtractThem
    end
 
    Then "it should be -1" do
      assert(-1)

        See the Then for addThem.
    end
  end

#  Scenario "Test subtractThem" do
#    Given "Test initialized with 2 and 3" do
#      start_test
#    end
#
#    When "I subtractThem" do
#      @test.subtractThem
#    end
#
#    Then "it should be -1" do
#      assert(-1)
#    end
#  end

end

Anything else I should be doing/not doing?
    If testing in Ruby, get to know Test::Unit.  In particular, learn most/all of the assertion methods that, I believe, are in the Assertions Module.  Know how to use them.  They're pretty easy to use. While you can use "assert" for almost everything, it's less expressiveand provides less specific error messages than using the correct assertion method.

    Understand that Coulda is two things:
   
    (1) Syntactic sugar around Test::Unit (again, know Test::Unit)
    (2) A tool for outputting tests in a nice human readable format.

    While I wrote Coulda with Behavior Driven Development in mind, it can be used for TDD (which is essentially BDD before the emphasis on getting the words right -- and anyone insisting otherwise is trying to sell you something) or, as you're trying to do, plain old ex post facto unit testing even.


I'm also working with Ramaze. Has anyone done anything with coulda/Ramaze?
    Not that I'm aware of but I'm eager to hear about your experiences with it as you make progress!

Evan

Scott LaBounty

unread,
Oct 2, 2009, 6:30:51 PM10/2/09
to cou...@googlegroups.com
Evan,

Thanks for the feedback. One question, you suggest:


<<
        def addThem
            @x_plus_y = @x + @y
        end
>>

which looks pretty "unnatural" to me and seems to be there just to make the testing work. Is that the case? Would people normally write code like that?

Scott
--
Scott
http://steamcode.blogspot.com/

Evan Light

unread,
Oct 2, 2009, 6:44:28 PM10/2/09
to cou...@googlegroups.com

On 10/2/09 6:30 PM, Scott LaBounty wrote:
Evan,

Thanks for the feedback. One question, you suggest:

<<
        def addThem
            @x_plus_y = @x + @y
        end
>>

which looks pretty "unnatural" to me and seems to be there just to make the testing work. Is that the case?
    Well, yes.  Actually, a better way to do it would be to leave your "MyTest" as it was and do the following in your test:


    Given "Test initialized with 2 and 3" do
      start_test
      # BTW, I would recommend against naming a helper "start_test" as it is not descriptive.  Instead, I would name it "create_test" or something like that.  But then I would not create a class called MyTest for real either (and neither would you I hope ;-) ).

    end
 
    When "I subtractThem" do
      @result = @test.subtractThem

    end
 
    Then "it should be -1" do
      assert_equal(-1, @result)
    end

    That's far far better.

    However, note that you've just coupled your Given to your When via the "@test" member variable  which is also obscured by your helper method "start_test".  You have also coupled your When to your Then on @result.  The coupling is not necessarily a bad thing but you need to be aware of it and manage it as you grow your test suite and factor out code.  As you DRY your tests, a practice that I recommend as you grow your test suite, understand that you are essentially building a testing DSL atop Test::Unit and Coulda as well.  Your own testing DSL/suite needs to be internally consistent in order to prevent bugs from occurring in your tests.


Would people normally write code like that?

    Nope they sure wouldn't write code like in my previous example.  Be it enough to say that today has been an eventful day and I wasn't thinking too clearly on my first email.  I'll stand by my responses above though.

Evan

Evan Light

unread,
Oct 2, 2009, 6:44:36 PM10/2/09
to cou...@googlegroups.com

On 10/2/09 6:30 PM, Scott LaBounty wrote:
Evan,

Thanks for the feedback. One question, you suggest:

<<
        def addThem
            @x_plus_y = @x + @y
        end
>>

which looks pretty "unnatural" to me and seems to be there just to make the testing work. Is that the case?
    Well, yes.  Actually, a better way to do it would be to leave your "MyTest" as it was and do the following in your test:

    Given "Test initialized with 2 and 3" do
      start_test
      # BTW, I would recommend against naming a helper "start_test" as it is not descriptive.  Instead, I would name it "create_test" or something like that.  But then I would not create a class called MyTest for real either (and neither would you I hope ;-) ).
    end
 
    When "I subtractThem" do
      @result = @test.subtractThem

    end
 
    Then "it should be -1" do
      assert_equal(-1, @result)
    end

    That's far far better.

    However, note that you've just coupled your Given to your When via the "@test" member variable  which is also obscured by your helper method "start_test".  You have also coupled your When to your Then on @result.  The coupling is not necessarily a bad thing but you need to be aware of it and manage it as you grow your test suite and factor out code.  As you DRY your tests, a practice that I recommend as you grow your test suite, understand that you are essentially building a testing DSL atop Test::Unit and Coulda as well.  Your own testing DSL/suite needs to be internally consistent in order to prevent bugs from occurring in your tests.

Would people normally write code like that?

    Nope they sure wouldn't write code like in my previous example.  Be it enough to say that today has been an eventful day and I wasn't thinking too clearly on my first email.  I'll stand by my responses above though.

Evan

Scott LaBounty

unread,
Oct 2, 2009, 10:27:29 PM10/2/09
to cou...@googlegroups.com
Evan,

Thanks for the help. Yes, I probably wouldn't do a few of the things I did here normally either. I now do see where you're coming from (and yes I most certainly understand "eventful" days).

I'll try doing this with a more "real" example and post what I come up with either here or on my blog or both and maybe you or others can help me figure this out a bit more.

Once again, thanks for the help!

Scott
--
Scott
http://steamcode.blogspot.com/

Evan Light

unread,
Nov 23, 2009, 5:45:47 PM11/23/09
to cou...@googlegroups.com

v0.4.0 adds support for Rails.  0.4.1, which I hope to have up later today, will get rid of those other gem dependencies.

On Oct 2, 2009 10:27 PM, "Scott LaBounty" <slab...@gmail.com> wrote:

Evan,

Thanks for the help. Yes, I probably wouldn't do a few of the things I did here normally either. I now do see where you're coming from (and yes I most certainly understand "eventful" days).

I'll try doing this with a more "real" example and post what I come up with either here or on my blog or both and maybe you or others can help me figure this out a bit more.

Once again, thanks for the help!

Scott

On Fri, Oct 2, 2009 at 3:44 PM, Evan Light <slei...@gmail.com> wrote: > > > On 10/2/09 6:30 PM, ...

Reply all
Reply to author
Forward
0 new messages