Many folks understand the importance of testing, the value-add, the business benefits of TDD, that’s why we were all there.  We got a thorough overview of the numerous testing products. And there’s a LOT out there… or maybe it just seems that way.  But once I was back at my desk facing my app, I still didn’t understand how to get started.

Yeah, I’ve tried a few tutorials but they often only utilize the irb command line and don’t really explain how everything fits into a real live rails application.

I’ve been told that testing is just one of those things where you have to just dive in and go for it.  That being said, let me share with you my recent endeavors using the Rails Guides and the little knowledge I’ve pieced together so far.

1.  Open your current ruby on rails project
Yeah, I said open your current project.  If you don’t get started today, working every day, it’ll never happen right?  But if you don’t have a current rails app and need some help getting started check out this Rails 2.0 step by step tutorial.

Okay now that we’re set up, we’re going to create a brand new model for the purposes of this testing tutorial:

>>ruby script/generate scaffold CoinChanger

By the way, don’t let anyone dissuade you from using scaffold.  It’s much improved over older versions since 2.0 and comes packed with all kinds of goodies incredibly helpful to the newbie.  You can always delete the files you don’t need later.

2.  Write a Test
What already? Yeah.

>> cd test/unit

You should see the stub of a test already here:

require 'test_helper'
class CoinChangerTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end

I didn’t find this too terribly helpful in getting me started. Let’s instead replace the stub code with this:

require 'test_helper'

class CoinChangerTest < ActiveSupport::TestCase

def test_return_correct_change
#setup
#exercise
#verify
#teardown
end

end

So, require ‘test_helper’ specifies the default configuration to run our tests. It appears in every default test file. Doesn’t seem DRY to me. I betcha there’s a config file in the augmented testing frameworks where this would belong. But for now, we’ve leave it.

Next, you’ll notice that our CoinChangerTest class is extended by ActiveSupport::TestCase. Now, this is a little different than what you might find in those irb examples I mentioned before. Those examples extend Test::Unit::TestCase. Now that’s totally fine when you’re running a bunch of isolated files in a tutorial, but not when you’re working with a real rails app.

The class ActiveSupport::TestCase extends Test::Unit::TestCase and gives you all the testing goodness you need to run fixtures. We won’t be playing with data and fixtures in this tutorial (stayed tuned for future blog posts) but we’ll use the ActiveSupport class since we’re testing a full fledged rails application.

After that we see a pattern that will guide us through every test we write:

• setup
• exercise
• verify (assert expectations)
• teardown

So, here is an example of a unit test:

require 'test_helper'

class CoinChangerTest < ActiveSupport::TestCase

def test_return_correct_change_in_pennies
   #setup
   @changer = CoinChanger.new
   #exercise
   hash = @changer.change_me("$5.87")
   #verify
   assert_equal 2, hash[:pennies]
   #teardown
   # delete files, close network/database connections
end

end

In the example above, we setup an instance of my model class:

@changer = CoinChanger.new

Then we exercise the method which should return a hash:

hash = @changer.change_me("$5.87")

Then verify that the implementation works correctly by asserting expectations :

assert_equal 2, hash[:pennies]

Finally it’s time to clean up. There is nothing to teardown in this example. If the test were creating files or network/database connections, then we’d use the teardown method to close out:

assert_equal 2, hash[:pennies]

3.  Run a Test
Go ahead. Try it out.

>> cd test
>> ruby unit/coin_changer_test.rb

Oh, dang! Get an error message?  When you’re testing a rails application, you need to be sure that your database.yml is set up and pointing to a valid database.  Those of you who just created a brand new rails app, you’ll need to edit your database.yml file.  I’ll assume you can do this on your own, seriously, take a look at the Rails 2.0 step by step tutorial.

Let’s try again.

Loaded suite unit/coin_changer_test
Started
E
Finished in 0.219 seconds.

  1) Error:
test_return_correct_change(CoinChangerTest):
NoMethodError: undefined method `change_me' for #
    unit/coin_changer_test.rb:11:in `test_return_correct_change'

1 tests, 0 assertions, 0 failures, 1 errors

Uh, oh. We forgot to create our change_me method in our CoinChanger model. Let’s do that now.

class CoinChanger
  def change_me( dollar_string )

    #transform dollar string into change
    return {}

  end
end

And rerun our test:

Loaded suite unit/coin_changer_test
Started
F
Finished in 0.344 seconds.

  1) Failure:
test_return_correct_change(CoinChangerTest) [u
 expected but was
.

1 tests, 1 assertions, 1 failures, 0 errors

Well, now we’re getting somewhere! The test failed because it’s returning an empty hash. Let’s give our test what it wants:

  def change_me( dollar_string )

    #transform dollar string into change
    return {:pennies => 587}

  end

So, now if we run the test again… hopefully we see this:

Loaded suite unit/coin_changer_test
Started
.
Finished in 0.219 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

This means the test passed and was successful. Yay!

Hopefully this is enough to get started. Stay tuned for more on testing!

Turns out that this is just more wacky Windows behavior.   RubyizednRailified explains in his post,  Installing Rails plugin from Github on Windows.  Thanks!

What annoys me about having worked with numerous flavors of SQL and databases is that the syntax tends to differ slightly.  On some dbs, this works just fine:

select *
into table1
from table2
where id = 1


But some dbs expect that table2 is some sort of variable rather than another table containing the same columns.  So on others (like MySQL), you need to do it this way:

insert into table1
select *
from table2
where id = 1

We recently had an issue with RedCloth and the Arabic character set.  When saving content, line breaks disappear when you create a new RedCloth object.  It’s as if the Arabic line break character is ignored.

I cut and paste my Arabic document into the text area box on the front page of the RedCloth site.  And the line breaks show up fine there.  So, the ajaxy bit works fine.  Perhaps the culprit lies in the .to_html method.

This could be an issue with the Windows-1256 charset for Arabic.  I wouldn’t be suprised if the problem doesn’t occur on a Mac which I assume uses ISO 8859-6.

Anyway, the workaround is easy.  Just use html line breaks: <br />

UPDATE: Had friends test this out on the mac using a variety of browsers and still had the same problem.  On either Windows or Mac, typing the enter key using the Arabic charset uses a strange character that RedCloth/Textile doesn’t understand.

In retrospect, I might have been better off implementing Authlogic.  But since I had already implemented Restful Authentication with all the bells and whistles in LittleVoice, it seemed to make more sense to simply throw in the open_id_authentication and the twitter_authentication plugins and be done with it.  Mistake #1

Redirecting to OpenID and Twitter via the form_remote_tag form doesn’t work.  The app just hangs.  I tried various options and incantations of form_remote_tag to no avail.  Forunately, I could just bypass this nuisance issue with a simple form_for.

Otherwise, Twitter worked well out of the box except for the fact that the api does not return a user’s email address after authentication for security reasons.  This bummed me out because the LittleVoice app has a business rule requiring all users to have a unique email address.  But problem easily solved by requesting email up front as part of my authentication form.  No big deal.

Open ID however has a number of quirks that caused me great pain to work out.  And in researching these quirks and issues, I had a hard time finding information short of digging into the OpenID api.  And who wants to dig into the api?  I don’t have time for that!  Mistake #2

Next, I found that my login and signup pages were working fine.  But authenticating via OpenID on the fly didn’t.  LittleVoice allows users to write a post before logging in, and rather than “submit” be able to login in-line.  But logging in via OpenID in the middle of my controller just wouldn’t work right.

What the heck was different between these two methods?  This is a great example of why it pays to be DRY.  But I digress…

In my sessions controller, I invoked OpenID in a form_tag that redirected to the open_id_logon named route.  In my other controller, I invoked OpenID by directly calling the authenticate_with_open_id plugin method.  Mistake #3

What wasn’t apparent right away is the fact that the authenticate_with_open_id method needs to be called twice.  This method redirects to the OpenID url entered by the user.  When the OpenID website is ready to return back to your site, you need to make sure that it calls authenticate_with_open_id again so you can grab the result, identity_url and registration object.  By calling the method directly in another controller, my return_to url was my controller method rather than the authenticate_with_open_id method.  Simply using the named route at all times, solves this issue.  But there’s another way.

There is a little known option for the authenticate_with_open_id.  You can set the return_to directly like this:

authenticate_with_open_id(openid_url, :return_to => open_id_logon_url) do |result, identity_url|
...
end

But here’s the really painful part.  When you try to use the return_to option you get an error message.

OpenID::Server::UntrustedReturnURL

There is a bug in the open_id_redirect_url method of the OpenIdAuthentication module.  The current module code looks like this:

def open_id_redirect_url(open_id_request, return_to = nil, method = nil)
...
open_id_request.redirect_url(requested_url, return_to || requested_url)
end

But it needs to be this:

def open_id_redirect_url(open_id_request, return_to = nil, method = nil)
...
open_id_request.redirect_url(return_to || requested_url, return_to || requested_url)
end

*sigh*  I can’t wait to close this ticket.

Here’s some of the feedback received:

So cool that folks travelled to Boston from as far away as PA to attend Ruby on Rails Workshop for Women!!

…it makes a huge difference to be able to ask someone stupid ?s.

I like being able to say that I deployed my first Rails application today before lunchtime like running a half marathon.

Totally impressed with the amount of Ruby and Rails info the students absorbed.

I want to thank the teaching assistants at #rorw4w. You were never judgmental and always patient.

You know what’s a lot of fun? TAing at #rorw4w.

It was indeed entirely attitude-free, as promised – unique in my experience! I appreciated that so much, and I had a lot of fun, as well.

I was truly impressed with the number of ror rockstars in the Boston community who were willing to give up their weekend to help some newbies.  I have a new mantra:  MINSBRAN – Matz Is Nice So Boston Rubyists Are Nice.  I will never fear going to another boston.rb or hackfest event again.

Sarah mentions all the awesome volunteers by name in her blog post, so here I’ll thank Berkman folk for their support in making this happen: Urs Gasser, Colin Maclay, Amar Ashar, Carey Andersen, Seth Young, Catherine Bracy, Jason Callina, Brandon Palmen, Dharmishta Rood, Daniel Jones, and the Gender and Technology committee.  I should also thank our CRCS supporters, Margo Seltzer and Salil Vadhan.

Tonight we gather again at the Open Source Code Crunch event at the Berkman Center. This is going to be a monthly event promoting mixed gender collaboration. Programmers will meet monthly and use their skills towards open source projects in a welcoming, collaborative, attitude-free, newbie-safe environment.  Looking forward to it.

ALTER TABLE contents CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

I would like to personally thank all of our generous sponsors who are making this weekend’s Ruby on Rails Workshop for Women possible. Thanks to them, attendees needn’t leave the workshop in search of coffee and food. But more importantly, we will be webcasting the event live! More details here.

While all our sponsors were enthusiastic about contributing towards childcare costs, Julia Ashmun was our sole individual contributor earmarking her donation to waive referral fees for attendees in need of sitter services.

Our first sponsor Hashrocket has got to be one of the coolest dev shops on the planet. (I am such a fangirl!)  If only because Desi Mcadam works there, founder of DevChix. Thanks for all your support, Desi!

Congratulations to EngineYard who just raised 19 Million with new investors. Nice to hear good karma coming back to good people.

We also send thanks to GitHub, the most popular Git hosting site. Brought to you by Logical Awesome. Don’t you just love that name?

And lastly we are grateful to RailsBridge for inspiring these workshops and reaching out to individuals and groups who are underrepresented in the community.

Thanks so much!! Can’t wait to meet everyone tonight!

The focus of the event is to encourage women to participate in open source development. So workshop coordinators made the request that men who wish to attend find a woman to sign up who might not otherwise have considered checking out a tech event. There was never any intention to exclude men from the event, but rather enlist their help in broadening the community.

What happens when you want to encourage mixed gender collaboration but your female friends and family are already annoyed with the amount of time you spend on the computer? And I suppose it’d be rather creepy to troll the highschool for geek girls. What’s a boy to do?

MINSWAN everyone. We’re opening the event up to anyone who would like to attend.

The majority of the response to the Ruby on Rails Workshop for Women has been encouraging and supportive.  EvenDHH himself tweeted about it:

Rails workshop for women at Harvard University on October 16-17:http://bit.ly/2pglhW — very cool!

Folks are really excited about it.  In fact, response is so great that I am seeking a larger venue for the THIRD time.

One of the reasons I love Ruby on Rails is because of its community. One of its treasured tennants is MINSWAN (Matz is nice, so we are nice).  This is what working in Open Source is all about.

I’m proud to say that many of the local ror rockstars will be at the workshop to TA.  And many of them are interested in pairing up with newbies of all genders at the monthly open source events we plan to host.  Why?  Because they believe that reaching out to folks who are underrepresented in the community produces better code.  And who doesn’t love better code?

You gotta be nice to be a real ror rockstar.  And there are a lot of nice people of all genders involved in this event.