Fitnesse (the extra “e” is for “excellent”)

May 21, 2009 at 8:49 pm (Javascript, Ruby, Week 9) (, , , , )

Today was my introduction to Fitnesse. I’d heard Micah and Doug talking about it, and of course I’ve read about the acceptance testing framework before, but I hadn’t every really looked into the code or used it outside of a few minutes during my interview here. As a high-level testing tool, it reminds me a lot of Cucumber. Both frameworks have a good argument for being the most customer-friendly. Cucumber is written in plain English sentences, whereas Fitnesse has a more complicated syntax to learn. On the other hand, Fitnesse is hosted in a wiki, so the acceptance test author doesn’t need to worry about using Subversion, Git, or any other source control management system. What we call “steps” in Cucumber are “fixtures” in Fitnesse, which may seem a bit strange to people coming from Rails, where fixtures are sample data (also for use in tests). I’ll have to get in deeper to see more changes.

I need to go through Brett Schuchert’s Fitnesse Tutorials to learn which commands are built into RubySlim (the language that runs the backend of our tests) and which were created especially for this project. I was able to get a couple of tests written towards the end of the day (with lots of help from test that were already written, and confirmation from Micah), but I’d have a hard time writing my own from scratch.

Micah and I wrote some AJAX code with JQuery that that ends up doing something similar to what we’d use RJS for in Rails (we’re using Sinatra). It definitely took a little longer than RJS would have, but on the other hand, we were forced to think about exactly how we were interacting between the browser and server. I’d done just a small bit of this before, working on a typing trainer web app for programmers, but this time I felt much more comfortable (my informal functional programming study helped, I think).

I drove Caleb to the train station after work, and we talked about his Tic-Tac-Toe implementation (he’s working on minimax right now). He’s doing his in Java as well, and it sounds like things are going great. My impression is that he’s done a better job of test-driving his work than me, though I’m getting closer to making it a habit. It’s inspiring to be surrounded by a bunch of motivated people who are all working to get better!

Advertisements

Permalink 1 Comment

Using Javascript to order the client around

May 17, 2009 at 10:00 pm (Java, Javascript, Ruby, Week 8) (, , , , , , )

Micah and I spent most of Friday working on a lightweight messaging system that’s going to allow us to push messages from server to client, even though the client is basically a web browser. Since HTTP is basically stateless, we’re doing it with AJAX requests (Javascript, with some help from JQuery). And in order to keep it really simple and flexible on the client side, we’re developing something like a message queue on the server, which builds up Javascript for the client to execute whenever it’s ready (this way the server keeps track of time-sensitive issues, and the client doesn’t really have to hammer the server to stay updated). It’s a pretty cool idea that Micah had; he likens it to us putting food on a plate (at the server), and when the client’s hungry, he comes along and takes the food that’s there and eats it (executes it in the browser). We’re using the command pattern to fill up the plate of Javascript.

The lunch & learn was a bit more technical this week (after last week’s great Star Trek excursion), but still great fun. Doug presented a prepared code kata: TDD factorials in C++. I had already seen a little of CppUTest from pairing with Doug earlier in the month, but he went a little more in depth explaining the syntax, which we had just kind of touched on before. He’s teaching a TDD class this week, which I’m sure will be awesome for anyone lucky enough to attend.

Eric Meyer presented the development of a story using acceptance test driven development (ATDD) with Cucumber. He and I had worked with it a good bit while developing our Rails app (which by the way has been live for awhile now): a job board for software craftsmen, so I knew the syntax and structure already. Eric used a great technique to get the story done quickly and correctly while doing a good bit of live coding as well: git tags. He had about 8 steps to the development of the story that he had practiced, and each one was tagged, so that he was free to code in a normal way and know that we could fast-forward to the next step at any point. I’d like to learn more about version control (both Subversion and Git), but it’ll just have to go in the bucket of stuff to learn with everything else!

In less technical news, I finally got a Cubs hat. Look out Chicago, now you might have to hear me say “Y’all” before you know I’m not from around here.

Permalink Leave a Comment

Let the names begin!

April 27, 2009 at 5:59 pm (Ruby, Week 6) (, , , , , , )

I decided it’d be better if I gave more semantically meaningful titles, so that people have more of an idea of what they’re getting into when they happily decide to read about what I did at work. Today, clearly, is an exception (at least as it relates to my learning), but let’s look past that and on to a future where I’m not speaking in numbers anymore.

Eric and I worked most of the day on behind-the-scenes work for our Rails app: mostly automating the deployment with Vlad the Deployer and writing automated browser-based tests utilizing Watir. Both technologies are pretty cool. I’ve lived with Capistrano for some time, though I mostly used the outstanding Rails Machine gem as a starting point. Well, it turns out Vlad owes a lot to Capistrano and Rails Machine as well, so it wasn’t all that different. There were a few gotchas I ran across, namely some weirdness with set deploy_via, :remote_cache, but for the most part we were just re-learning how to set a deploy recipe up from scratch. Not too difficult once we found the list of Vlad variables, and it’s great to have things automated now instead of having to SSH in manually and make the changes we need.

While we’ve done our unit testing with RSpec and used Cucumber for most of our integration tests, we found that there were certain things we needed Watir for: SSL and Javascript testing, in particular. I’m pretty certain there’s a way to hook Cucumber up to Watir, but we ended up just wrapping these new Watir integration tests with RSpec, which works just fine for our current purposes. There were a few problems that required us to SSH into our staging server (which we’re running these Watir tests against), but once we figured out the syntax for multiple SSH commands on one line, we were home free (we have SSH keys set up to manage the login process, which I highly recommend for anyone managing servers):

ssh colin@jones.com 'cd /path/to/application/current/; rake do_task'

The single quotes are the key! Once again, thank you Google.

I also did a story by myself where our error page has a form to submit your email address if you have a problem and would like to hear back from the support team. Hopefully that story won’t see a lot of use, but I’m proud of it. The code is clean and will be easy to maintain, and there are good tests for it. I hope I’ll be able to say the same about my Limelight app once it’s done.

Permalink 2 Comments

Week 2, Tuesday

March 31, 2009 at 6:57 pm (Ruby, Week 2) (, , , , , )

Today was my first day of really serious pair programming: Eric Meyer and I worked on a Rails application, learning Cucumber together along the way. Some of the most interesting things I’d read about pairing really proved true for me today: it was more fun than developing alone, it made me concentrate more and think through decisions better than I would alone, and it definitely gave us a better result than I’d get alone (I can’t speak for Eric!).

Cucumber is a great acceptance testing framework. The idea is, you write the tests in plain text, then wire them up using regular expressions to Webrat, Selenium, Watir, Mechanize, etc. There is a little more structure than that, but your best guess is to jump right in and try it out. Even if you’re not doing unit tests, these can really prove that a given feature works, and it only takes an hour or so to really get the hang of it. Cucumber even generates regexes for you to copy and paste, based on your Givens, Whens, and Thens. If you’re interested in learning Cucumber, check out Ryan Bates’ Railscast on Cucumber. It’s really clear and you don’t need to be experienced with testing to understand it (and it’s brand new – just came out yesterday). I’d definitely start here if you’re doing Rails work and are interested in getting into testing. And if you’re doing Rails work and NOT interested in getting into testing… Well, I’d still start here.

It’s nice to be doing Ruby again, where I have a lot more experience, but I quickly realized that the way I did Rails isn’t anything like the way 8th Light does Rails. Basically everything gets unit tested, including views. One result is that I’m very confident about the solidity of this application after running all of the specs, but another equally important one is that when things need to change, we find out very quickly when things get broken, and we know when everything is fixed. So we don’t waste time click-testing through sample user workflows as each change gets made, but we still know we’re OK.

I had to stop our coding process several times to ask questions and sometimes just look at the code for another minute or so to absorb the reasons for testing decisions. Mocks and stubs are looking more normal, and I’m even starting to notice ahead of time when one will be needed. I still struggle with starting out on a testing path, and I’m sure it’ll stay that way for awhile, but I know I’ll progress with time and experience.

Permalink Leave a Comment