Falling in Love with DSLs

We were recently given a free day at work to hack on a project that was outside the realm of our normal responsibilities, yet could still be beneficial to the company. We were encouraged to be creative, explore ideas that interested us, and see if we could come up with something to demo at the end of the day.

Service level testing, or functional testing, has been a hot topic at work recently. It’s no secret that we have a very large SOA at Orbitz, powered by Jini. Services, calling services, calling services…you get the picture. Historically, we have not been the best at automating the testing of these services. That is beginning to change. About two years ago, the team I work on developed a test tool that allows us to interact with our services at a very high level, keeping us out of the nitty-gritty details when invoking a service. It’s a command line based tool with a very simple, intuitive syntax. All of the details are accessible if we need them, but more often than not they just get in the way. In fact, we enjoyed working at this level of abstraction so much, that I wrote a functional test framework (named jwoodunit by my co-workers) that drove service level tests against our services, which were written in this same “language”. It allowed us to pump out service level tests is very short order that were easy to read, and easy to maintain. It has only just occurred to me that what we had created was really a Domain Specific Language (DSL).

We have a fairly large quality assurance team that is made up mostly non-developers. Most of the testing that is done is manual, or driven by an automation tool similar to Selenium. The problem is that the manual testing is slow and not reliable, and tools like Selenium tend to be brittle, since they are based on the layout of the HTML page. It also prevents you from testing any service that is not directly accessible through the web application. So, for my project, I wanted to see if I could take my team’s DSL, clean it up even more (it is still very “programmy”), and give it to our quality assurance team so that they could test our services in a more reliable fashion.

What I ended up with was a very high level, English like DSL that I call Trastel (Travel Service Testing Language). Trastel is implemented in Ruby. In fact, it’s safe to say that Trastel is Ruby. I didn’t implement a new language. I simply took advantage of Ruby’s fantastic meta programming capabilities to extend the language with functionality that is needed by the tests. A example test is worth 1000 words:

search.flights.on("orbitz").where(
   :origin => "ORD",
   :destination => "LAX",
   :departure_date => "2008/12/10",
   :return_date => "2008/12/15"
)

verify_at_least_one_result

foreach_result do
  verify_equal "ORD", origin
end

This does exactly what you’d expect. It searches flights on Orbitz, flying from Chicago’s O’Hare airport to Los Angeles International Airport on 2008/12/10, returning on 2008/12/15. We then verify at least one result came back, and that the origin of each flight is O’Hare. That’s it.

Implementing this test in Ruby was a breeze. Since everything is an object in Ruby, dynamically adding methods to the Object class gives us the ability to create pseudo-keywords, like “search”, and “foreach_result”. Trastel also sets an attribute named @response on the test, so the code that implements the verify methods can just check that, instead of having to specify that your checking the response of the service call. foreach_result will iterate over the @response if it is an array, yielding to the specified code block for each item in that array…giving us an easy way to check each element. The last bit of magic surrounds the “origin” method. “origin” isn’t a method on object. It’s a method on the the type contained in the @response. Thanks to Ruby’s method_missing method, I can forward that method call onto the object in the @response for it to tell me what origin means. Nice and easy.

Another great thing about Trastel is that it sucks in Active Support. Active Support brings with it a wealth of extensions to the core ruby classes, letting us do something like this:

search.flights.on("orbitz").where(
   :origin => "ORD",
   :destination => "LAX",
   :departure_date => 4.weeks.from_now,
   :return_date => 6.weeks.from_now
)

We still do all of the heavy lifting (creation of the service request, execution of the remote service, etc) in Java, using JRuby to get the Ruby code to play nice with the Java code. But, the DSL serves as an excellent means to collect the data needed to drive the test, call the Java code to invoke the service with that data, and verify the data in the response matches what was expected. It successfully keeps the person writing the test from having to know anything about actually invoking the service. Writing tests at this level of abstraction also shields us from the majority of service API changes that may come our way.

With all of the benefits that I can already see with this still very immature DSL, I’m kicking myself for not considering DSLs more seriously in the past. They have been around quite some time, and have had many well know developers singing their praises. I’m looking to see what other problems I’m currently facing that could be solved a little easier by letting me code a little closer to the domain. Had I know that it would be this simple, maybe I would have tried it a long time ago.

Diners Club Webapp Has Been Released

I finally got around to cleaning up and publishing the code for the Diners Club web application. Like everything else I release, I’m not sure who will actually use it. But, I find that the whole exercise of releasing your code is beneficial to you and your code. So, it’s worth the effort. It’s available via the MIT license, so have at it.

Kind of a funny side note about this project. I recently found out that a couple of co-workers of mine spend some of their spare time working on Planypus, which is a site for making plans with your friends. Sounds familiar! I was talking to them, and it turns out that Planypus started the exact same way that the Diners Club webapp started, as just a way to organize dinner outings with friends. They however took it to the next level and threw a business plan around it. I’m just not that business savvy I guess :)

Bugzilla and SMTP Authentication

The last few months I’ve been helping out in an effort to upgrade Shotokan Karate of America‘s membership management system. They’re rewriting the system from scratch, as the old system has grown to be unmaintainable. The code for the new system was about 85% complete when I signed up, so I offered to start testing the system while the sole developer working on the project finished up the code. There were no unit tests, so I figured that would be a good place to start. This naturally brought up the issue of how we would communicate problems and fixes, so I offered to install Bugzilla on my Linux box and suggested we use that.

It wasn’t until later that I found out that Bugzilla and SMTP Authentication do not get along (although I see that there is a fix in the pipeline). Bugzilla supports SMTP, but without authentication. It also supports sendmail, but my ISP isn’t too keen on people running their own mail servers, making the use of sendmail difficult. Since my ISP has a SMTP server for me to use, I figured I would use that. But, authentication is required on that server.

I toyed around with some ideas in an attempt to keep me from hacking the Bugzilla code. One involved parsing the data/mailer.testfile file (where mail is sent when the “testfile” mail option is set) for the To address and the email body, and sending the email via a custom script. But, that brought up some interesting race conditions if multiple users made a change that triggered an email at approximately the same time. We would need to periodically read that file to send the email, wiping out the contents afterward to avoid resending the same messages. If the timing was right, we could potentially wipe out a message that was never sent.

I took a look at the Bugzilla code, and found the module that was responsible for sending the email. The code was clean, and pretty easy to follow, even though I know very little perl. I found the point in the module where it calls out to the Mail Transport Agent to deliver the mail. I figured I could easily insert a call to a script to deliver the mail, using SMTP Authentication. That is exactly what I did. I modified BugMail.pm to include the “system” call below.

sub MessageToMTA {
    ....

    # --- Begin New Lines ---
    system('send-bugzilla-email.rb', $msg);
    # --- End New Lines ---

    $mailer->open($headers->header_hashref);
    print $mailer $body;
    $mailer->close;
}

$msg is a variable that contains the SMTP message to send. That message includes the To address, the subject of the email, and the body of the email. In other words, everything we would need to send the mail ourselves. I then wrote a ruby script to parse the message, and send the email. Here’s the script.

#!/usr/bin/ruby

require 'net/smtp'

from_address = 'username@my_isp.com'

# Break the message up into an array of strings
message_array = ARGV.first.split("\n")

# Pull out the To address and the subject
message_array[1] =~ /^To: (.*)$/
to_address = $1

message_array[2] =~ /^Subject: (.*)$/
subject = $1

# Delete some crap that we do not care about
4.times { |i| message_array.delete_at(0) }

# Combine what remains back into the body
body = message_array.join("\n")

message =  "From: Bugzilla <#{from_address}>\n"
message << "To: #{to_address}\n"
message << "Subject: #{subject}\n"
message << body

# Send the email
Net::SMTP.start('smtp.my_isp.com', 25, 'my_isp.com', 'username', 'password', :login) do |smtp|
  smtp.send_message message, from_address, to_address
end

File.open('/var/log/bugzilla_email.log', 'a+') do |file|
  file.puts("\n-----------------------------------------\n")
  file.puts(message)
end

Although not ideal, it does the job. And, if I do say so myself, it works quite well. I’ll be looking forward to upgrading to the new version of Bugzilla once it supports SMTP authentication. In the meantime, this will keep things rolling.