Posted by rick Mon, 20 Feb 2006 20:46:00 GMT
Check this out. Jonas Bengtsson has released a new screencast showing how to integrate Ruby and Selenium for browser-based acceptance testing. Bonuses include use of the Selenium IDE, Ruby test authoring, and automation of both IE and Firefox (on Windows, granted, but it’ll be cross-platform shortly, I have a feeling).
Very cool.
Posted by rick Wed, 08 Feb 2006 21:31:00 GMT
Ruby on Rails is big on testing. There’s support for unit testing cooked right in—every time you create a model you get the unit testing framework built for free—just fill in the blanks. Similarly, whenever you create a new controller, you get the functional testing framework built for free—just fill in the blanks. Seems like view testing (with Selenium and OpenQA) is moving forward, and I wonder if some sort of automated support for those won’t come from the Rails framework itself soon…
That said, there’s very little talk about testing helpers—those bits of Ruby code that are made available for use by the view, but which aren’t in the templates themselves. Helpers aid reuse, and are a valuable use of Ruby behind the template.
Certain helpers can be tested with test/unit, just like unit tests for models. Some helpers, though, call functionality in the view libraries: a really common idiom is to provide various foo_link() methods that will generate links to certain types of objects. Rather than repeating the same detailed ActionView link_to() call everywhere, the code is factored out to a helper method which assembles the appropriate information and calls link_to() for you. Then you’ve got a single point of change whenever you want to change how comment links, story links, user links, whatever, behave.
Testing this sort of code should require a functional test, since you’ll actually want to have the view instantiated. There’s seemingly zero documentation on how to do this, and, checking around on some existing Ruby projects, I see people writing these sorts of helpers, but I see noone actually testing them.
We’ve jumped back for a moment and are relying on “stub” code to allow us to get a primitive, but less than ideal, test of our link helper (and other similar helpers that call ActionView functionality). We’re now looking for guidance from the Rails community.
To that end, we’ve posted Rails ticket #3775.
Posted by greg Mon, 06 Feb 2006 19:46:00 GMT
We had a brief introduction session about RJS templates (a way to automate AJAX actions for Rails) recently. The HOWTO document appears below. We've also provided an mp3 download of the audio from the presentation we had for the team. Read more...Posted by rick Wed, 18 Jan 2006 21:08:00 GMT
Sorry it’s been a while since I’ve given an update (we just cleared milestone08, fwiw, and I hope to have more for you shortly)—we’ve been making good progress, are having visitors from outside over the next couple of days, have had our heads down working hard, and are preparing for some internal presentations on our progress.
We recently had a big hiccup though. Just as we were working on hiring a new person to help out on the development team, our technical lead got a big offer out of the blue from a company in the, shall we say, financial realm. A bigger offer than we, as a non-profit (granted, a big non-profit but a non-profit nonetheless) can hope to match. So, long story short, we’re losing a real quality employee and member of our team. We wish him and his family the best and are excited for him in his new opportunity. Still, we’ve got a job to do, and we wish we could keep him.
But, we lower our heads and keep on keeping on.
So, now, in addition to needing to fill one highly qualified slot that we were going to expand with, we need to backfill another highly qualified slot to keep our momentum.
So, we’re looking. We’re looking for Good People… like the ones we already have (I wish we could clone them, but alas, we don’t have the requisite growth chambers installed yet…). Ruby experience is required, pretty much as is familiarity with Rails. We need people who can think in terms of architecture and domain models, can sit down and talk to users about how the system we’re building will work for them. We need people who like to work in a team, who aren’t afraid of unit tests and functional tests, who have a good sense of humor, who are excited about building awesome software, and who don’t break the build too often.
We’re working with cool tech, with slick processes, on a big project for a good cause. When we roll out the software we will just be beginning the process of improving the way we help people. Along the way everyone will learn a lot.
We’re in Nashville, TN. We can get some help from developers who aren’t in Nashville, but the real leverage comes from people who can be here to draw on the whiteboard with our developers, to point to code on the screen, to read the body language of the customer as he explains his job.
If you’re intrigued by the possibility of doing Ruby on Rails work in a cool town on a great project for a good cause (oh, yeah, for good money), then drop me a line.
Email me at rewritework at rickbradley.com.
Posted by rick Wed, 16 Nov 2005 16:32:00 GMT
In September (or so) we went through the process of trying to decide whether we wanted to keep plowing through the JBoss Java stack we were building with or to pursue an alternate technology. We did some test prototyping of part of our first component (of 6) in Ruby on Rails and then a test re-implementation of the full component in Ruby on Rails.
The productivity increase (and code footprint decrease) was basically staggering. We undertook a full analysis of the consequences of shifting our development from our Java stack to a Ruby on Rails platform. Ultimately we decided to shift from Java to Ruby on Rails.
The summary document of the issues (edited to protect the guilty :-) can be found on this site at Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite.
