In Part 1 of this series, I walked through the development cycle of the "user views candidates" feature.  In this article, I am going to implement the "user searches for candidates" feature, focusing on unit tests and refactoring. I will not show all the detailed steps - for a step by step walkthrough on implementing features following the BDD Outside In way, please see Behavior Driven Outside In Development Explained, Part 1.

Let's first write the cucumber feature: 

And run the cucumber test to see it fail. The test fails because it tries to fill in a search term in the "search" text field, which is not on the page yet. We will add that part of the page:

We'll run the test, create a new route for searching candidates, and create the "search" action on the candidates controller.  We are adding two exposures to get the search term parameter and ask the model the search for candidates. Again the test will fail, telling us that we need to implement the search functionality on the model level.

Now we've dropped to the inner BDD circle again. Let's first write a spec to express how we expect the search to function. The spec has 7 examples, covering cases with one word, two words, partial words, empty string, and search with a multi-word last name. It is much easier and faster running to provide comprehensive test coverage for the candidate search function on the unit test level (Rspec) than to do it on the integration test level (Cucumber).

Let's first let the test fail:

It took me a few tries to let the tests all pass - I settled with a solution that I would create a new database column "full_name" which is automatically updated when candidate is saved with concatenated first name and last name.

We will run "rake db:migrate" and "rake db:test:prepare" to migrate the development and test databases. The candidate unit tests now will all pass - also telling us that though we changed the way full_name is implemented, we didn't change its behavior.

Now let's jump out to the integration / cucumber test circle, and this time it will just pass. We can run the whole test suite again to insure that we did not introduce any regression bugs - one of the best benefits for the BDD, is that most bugs are caught right when they are introduced, and they are much easier to fix when the programmer still has the domain and context fresh in mind. In fact I can remember when I didn't do much testing it was not uncommon for me to spend at least half of my time fixing bugs (many bug fixes introducing new bugs!), while at Hashrocket I spend almost all my time implementing features.

Now that all tests pass, it's time for refactoring ("Refactor in the Green", as the saying goes). The "list candidates" and "search candidates" features share a view, but we are relying on the presence of the search_result exposure to differentiate showing search results or all candidates and this is quite ugly. A better solution would be to make search a scope on the candidate model that just passes through if no search term is present. We can chain the search scope within the candidates exposure in the controller and remove the condition in the view.

The code is now much more succinct and the logic is simpler. We will run the complete test suite again to make sure that everything works and they do. The test suite we built up along the way gives us great confidence in the refactoring - so that we actually do it often and keep the code base clean.

This is it! Leave some comments and let me know what you think.

The source code is here on Github. 

Following the failure message, we will create a fabricator:

Test Driven Development (a subset of Behavior Driven Development) tells us to just implement enough code to make the test pass or get a new error. We will resist the urge to go further other than just defining the fabricator. Let's run the the cucumber command again. And this time, the test tells us that there's no class for "candidate". 
 

We will generate a "candidate" class, and see how the test tells us to do next: 

The test is telling us now that our next step should be to create a migration to create the database table for "candidates". 

we will run migrations for both the development and test databases, and run the cucumber test again: 

This time it's telling us that cucumber doesn't know how to map "the candidate list page" to a path. Let's create this mapping in the feature/support/paths.rb file. We will add the regular expression /the candidate list page/ and point it to "candidates_path", and create a new route to point to that path. 

We will run the test again - the route we just added is trying to route our request to CandidateController, which, at this time is not yet defined. 
 

We will generate the controller and the logic in the controller to get all the candidates. Instead of creating an "index" action and put candidates in an instance variable, In Hashrocket, we use  decent_exposure  (by our very own Stephen Caudill) in controllers to maintain states - please see this article where Stephen explains the rationale behind it. For now, we will just expose all candidates to be available in the view. We do not need to create an index action in the controller because decent_exposure takes care of it automatically.

We will also create a view to show a list of candidates in a table (we use haml and sass on the front end). 

Note that in the view we are calling candidate.full_name for the first column because that column needs to be the full name of the candidates. We do not have the full_name method defined for the candidate model yet therefore it will fail again.

Still remember the circles? Now we are dropping down to the inner circle of domain models. To test drive this level of the application we will rely on Rspec and unit tests. We will create a spec file for the candidate model and put in our expected behavior the "full_name" method: 

Just like on the outer circle, in this inner circle we also follow the "red - green - refactor" cycle. So we will first run it to see it fail. 

Then we will implement the full_name method in the candidate model, run the spec to see it pass. 

This is a very small piece of implementation so there is really no need for refactoring at this point - we will skip the refactor step (I will cover refactoring in part 2 of this article). Now that we completed the inner circle of model and unit testing, let's jump out to the outer circle and run our cucumber test:

This time the test tells us that it cannot find "Bart Simpson" in the first cell in the table, and this is most likely a data related issue - we will throw in the "show me the page" line to see the screen right where it failed. 

Looking at the page, it looks like that the result table of the 3 candidates are not sorted by first name as we wanted.

We will go to the candidate model and add the sorting into the exposure of the candidates controller:

We run the cucumber test again and this time it passes!

As the last step, we will open up the browse and actually manually test this feature to make sure they work as desired - in this case we will need to create some candidates in the console first then we can see them listed, nicely sorted. 

 

 

 

 

I am going to do a hack + learn session this weekend to develop a Ruby event based / async server for the Snake game. I looked at several technologies in this space and decided to give Faye a try - Node based solutions are pretty cool too, and I’ll use another time to do a project on that.. 

What Faye really impresses me is that it’s rack based, so it is trivial to integrate it with Rails applications, and can easily leverage the other awesomeness in the Ruby ecosystem (the language, gems, hosting, etc). 

On the front end, I am going to use HTML5’s web socket and canvas to control the snake.. should be interesting. 

I’ll be doing this with some people together this weekend. if you want to join please tweet me @knwang - we’re all remote and planning just to use IRC to share and discuss. 

Some related reading: 

http://railscasts.com/episodes/260-messaging-with-faye

http://faye.jcoglan.com/

http://diveintohtml5.org/

 

Keynotes of Day 4 were some of the best:  Check out Corey Haines keynote here on becoming awesome. and if you are a manager and claims that people are your best assets you need to check out how to optimize for developer’s happiness. Glenn Vanderburg gave an insightful presentation comparing software engineering with other engineering disciplines - are we craftsmen, engineers, architects, artisans all of the above, or none of the above? Watch it, it’ll be worth your time. 

Yehuda Katz / @wycats talked about “Building Rails Apps for the Rich Client”. I thought he was going to talk quite a bit on SproutCore but he barely touched it. I could not find the presentation for this so here is a summary: 

• Rails can be very useful in making APIs for machine to machine communications. 
• Q: If all I need is JSON, why do I need Rails?  Isn’t something like Sinatra better? 
• A: Rails is not trivial, a lot is hidden. It’s a rich abstraction of HTTP. It takes care of a lot for you: sessions, cookies, security, standards, constraints, caching, etc. If you move away from Rails you have to do these yourself. and it’s hard to make things work well together. Rails does a lot of awesomeness underneath. 
• Some rules on API design: 1) root has to have resource keys 2) no nested URLs. 3) nested object should follow 1) and 2)

Passing JSON back to the rich client to have a JavaScript templating engine (SproutCore, Backbone.js, Mustache.js etc) to render is a trend.. and Yehuda is making the point that Rails is still a good choice for building APIs. 

I picked up some nice tips from the “Bridging the Gap between Rails and JavaScript in Rich Client Apps” session (presentation here). A very brief summary - how to reuse code across Ruby and JavaScript in your app? 

• Write JavaScript code in CommonJS modules
• Use IncludeJS to use them in Ruby
• DRY!

Matt Kelly / @mkelly12 gave the presentation on Backbone.js, a popular JavaScript templating engine. As I said before, having a MVC front end structure is a trend building rich client apps… and it can really do magic.. check out the Chop app that backbone guys just released (make sure to drag and drop on the code). The presentation itself is a lot of fun too!

FINAL WORDS: 

I got a lot from this conference - it has certainly been information overload, but I came back home excited about all the people doing interesting projects. Met many people who I have known but never got to meet in person. It is very true that open source is all about the community, and RoR has the best community there is.. it almost feels like a fraternity. 

Day 3: 

Dr. Nic  @drnic ‘s opened up the morning keynote to talk about Ruby’s history, but it’s really from Engine Yard to get folks to use JRuby and Rubinius.

Aaron Patterson / @tenderlove (only person in both Ruby core team and Rails core team) gave an “Intense” keynote - you have to see it to know what’s in it - it’s definitely more than you think. :-) He dived into some under the hood stuff in Rails 3.1 improvements  - prepared statement caching, new serialization strategies, streaming response, reduced middleware stack. 

The “Controlled Choas” session is a case study of NASA transitioning from legacy system (yes, Java is now considered Legacy now!!). The reasons behind the switch are 1) they want a easier interface (SOAP to REST) and 2) They started to lose developers because nobody wanted to work on old technologies. They switched to JRuby to make use of the JVM. The result: happy developers, team moving much faster, much more maintainable code base. 

The two BoF sessions I went to were awesome -

Ryan Bates / @rbates (of the Railscast fame) led a walkthrough on the Cancan gem 2.0 version (for role based authorizations). It’s still under development.. but is a huge step over 1.0. I have actually evaluated Cancan for one of my projects but found it somewhat limited on the finer level of controls. 2.0 would change that - I like where this project is going. 

Yehuda Katz gave a presentation on SproutCore. This is one of the things coming up that I am really excited to dig into (the other is the Ruby EventMachine). It has matured much from when I looked at it last time - for one.. there’s online documentation now! I think desktop like web applications are the way to go, and it’s really cool to have a framework like SproutCore to make things easier. There was a heated discussion on SproutCore vs Backbone.js and Yehuda’s message was: SproutCore has everything Backbone (mostly observers) has and more, and the argument that SC is too big is not so important in the bigger scheme of things. 

My intention was to write one blog post per day chronicling my experiences but that turned out to be very difficult - sessions ran into late evenings (some BoF sessions ran as late as 10pm, but were really worthwhile), plus the casual chatters and the happy hours.. recovering from jetlag from Asia didn’t help either.. so didn’t get to write on it until today. 

But here it goes: 

Day 2:

@dhh gave the keynote in the morning to unveil Rails 3.1 RC - asset pipeline, jQuery default, native CoffeeScript + Sass support and all. No big architectural changes but solid steps to make Rails more organized. He also hinted that pjax and backbone.js could be there in Rails 3.2 (presentation layer MVC is a recurring topic this year).

Jeff Casimir / @j3 gave a very nice session on “Fat Models aren’t enough”, where he talked about better organization of code in the models, the presenter pattern (don’t just pass a bunch of instance variables into the view, pack them up in a presenter class), scopes (or the no need of ) with lots of code snippets. Presentation here. 

Another session that I found really good is “Confident Code” by Avdi Grimm / @avdi. Presentation here. He talked about the Nil objects being over used in Ruby is so true. The idea of killing all nil in the code is refreshing (therefore eliminating all the checking).  I’ll certainly incorporate that in my code.

Eric Ries, the godfather of the “lean startup” movement gave the evening keynote. I’ve seen him speak before, but it makes me think every time. If you are into building a software product start up, his work is a must read. Video is here. 

Day 1 of RailsConf is the day of tutorials, which turned out to be quite good. 

I attended the HTML5 session by @subelsky in the morning and learned a bunch. Like everybody else, I have heard about the HTML5 buzz for a while, but never got deeper into it than scratching the surface. The session ran in the form of 13 labs, and drawing, sockets, native storage, and of course native media support are the highlights. In fac you can do many cools things with just html5 now.. such as this game. The presenter did a great job packaging the material as a series of easy to follow labs. You can get them here and follow it. It will all just take a couple of hours. 

I went to “Building Bulletproof Views” in the afternoon by the LivingSocial guys.. Solid presentation and I learned quite a lot.. I tend to agree with them that the rails view layer is wild west and is probably the least organized part of the framework, and I didn’t see much “best practices” before on this layer - good work that they put this together. Interestingly, I found half of the issues are made really easy with using an authorizing framework like Compass. They also talked about some tools like formastic, goose (a gem for tab navigations), responsive design and the mobile web. Presentation is here. 

Also, the Envy Labs guys gave sessions on Rails for Zombies (beginner’s course to Ruby on Rails) and Rails Best Practices. Check them out. 

Finally, IgniteRails is awesome! @drnic is hilarious.