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!

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.

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.

Thanks so much for organizing the workshop. I hope to attend. I love the idea, think these workshops are necessary, and would love to help out in the future if you need.

Personally, however, I do feel that the following, “Men are warmly welcomed when they find a woman who wants to learn Ruby on Rails who will register and bring a guest.” is exclusionist.

I have been in scientific software development for many years. I am also a wife and a mother of two. I agree full-heartedly that women in technology and certain areas of science face many struggles, discrimination, and blatant sexism. We might bridge the gap better though with more welcoming attempts that seek to include, but educate men in our struggles. We can’t do this though if they cannot join our events – outright. Perhaps in the future, you could just sell the event as simply women-in-technology focused, but leave the door open for men as well?

I understand the need, but the registration restriction is illegal:

“No person in the United States shall, on the basis of sex, be excluded from participation in, be denied the benefits of, or be subjected to discrimination under any education program or activity receiving Federal financial assistance…”

Title IX of the Education Amendments of 1972

Folks, I do not consider this workshop to be exclusionary especially considering that the current ratio of women to men is 2:1.

The point of the event is to encourage women developers. So the caveat that a man is asked to encourage a woman to sign him up as her guest feels entirely appropriate.

Besides, there are many many other tech events that are primarily male driven. And sadly many of these events do tend to be exclusionary to women through subtle competitive atmospheres and in some cases not so subtle sexist comments. Just check out the geekfeminism wiki regarding recent tech events for more notable examples.

Starting in November, we will be having a regular Wednesday evening event pairing newbies with ruby on rails rockstars to work on open source projects in a welcoming, collaborative, mixed gendered environment. (Meaning that men are very welcome to attend on their own.) The idea is to encourage learning rather than the competitiveness found in other tech events. And “educate men in our struggles” by working alongside them.

No. I will not rescind the “come as a guest” request for this ONE event. It is my understanding that making a “request” is entirely legal.

p.s. Boston ruby group is a lovely group of people and I do not include them as part of the exclusionary tech events referred to above.

How can it not be exclusionary when you advertise that a man is only allowed to attend if accompanied by a woman, but a lone women is fine?

It most certainly IS illegal, even just to advertise it in that way.
Consult a lawyer unless you wish to risk Harvard losing federal funding:

Title IX is administered by the Office for Civil Rights in the U.S. Department of Education (OCR).[3] It applies to an entire school or institution if any part of that school receives federal funds; hence, athletic programs are subject to Title IX, even though there is very little direct federal funding of school sports.[4] The regulations implementing Title IX require all institutions receiving federal funds to conduct self-evaluations of whether they offer equal opportunities based on sex[5] and to provide written assurances to the Dept. of Education that the institution is in compliance for the period that the federally funded equipment or facilities remain in use.

The intention is admirable, but the implementation is legally flawed.
Just because it “feels entirely appropriate” doesn’t make it legal!

I appreciate you pointing the legalities of the event. I’ve contacted our clinical office to confirm.

But I won’t allow you to ignore the more important part of my message regarding the exclusionary tactics of other “open” tech events.

Rather than welcoming men as guests, perhaps we should simply make sexist comments and harass them into not attending. Apparently, that must be completely legal since it happens regularly.

This evening, the announcement was sent out via the internal Harvard ABCD group list which emails all the techies working at Harvard. And I have to admit to being flabbergasted at the following responses sent to the entire ABCD community:

This is blatant sexual discrimination. Are women considered too fragile to learn technical subjects in the same group as men?

For whatever it’s worth I think XXXX is right.
Can you imagine the reaction if there was a technical conference for men only – and a women could only attend as the guest of a man?
There are far too many grants/scholarships/opportunities that are explicitly only open to women or minorities (I’m a minority and it still bothers me). A hypothesis of implicit discrimination against group A does not justify explicit discrimination against group B.

This women’s Ruby workshop exists for the same reason this men’s knitting retreat exists  http://www.menwhoknit.com/community/?q=n…). I have never heard a woman knitter complain about a men’s knitting class.

Well, to be fair, I think a male-only knitting group is just as bad an idea as the women-only RoR workshop

This was my response:

If anyone has concerns about this workshop, please email me directly as I am the coordinator.
But I feel that I must add that for those of you who don’t understand the need for this sort of workshop, you might want to read this keynote talk by Kirrily Robert.

A lot of people, still just don’t get it.  Folks don’t want to believe that there are still sexist jokes, pornographic presentations at conferences, harrassment, and all kinds of subtle discrimination going on in the tech community every day.  And the only way to combat it, is to encourage mixed gendered environments so that both sexes can learn from one another.

This workshop happens to be very male friendly.  At present, the women to men ratio is 2:1.  If you can’t find a mother, sister, daughter, friend or stranger to sign up with you for this class, then you have more problems than a one day programming course is gonna fix.