Bootstrapping the User Interface
Now that we have a model we’re happy with, we’re going to wrap it in a simple user interface that allows the user to specify how much cash they want to withdraw. Even though it might not be a typical choice for a real ATM, we’re going to use a web form. We’ll use the Sinatra[37] web framework to serve our user interface, and we’ll use the Capybara[38] gem to automate it. We won’t go into much detail about how Capybara works here, but you’ll learn much more in Chapter 15, Using Capybara to Test Ajax Web Applications.
We’ll start by adding the necessary gems to our project and getting the web server up and running.
Installing the Gems
Our app is growing up. We need to install another couple of Ruby gems, so let’s create a Gemfile to manage the project’s dependencies using Bundler.[39]
In the early days of Ruby there wasn’t an easy way to share and install third-party libraries. They would be scattered around the Internet in tarball archives, CVS and Subversion repositories, and people had to manually download them and copy them over to their own projects.
In 2003 the RubyGems package manager appeared, and from Ruby 1.9 in 2007 it became part of the standard library.
Fast forward another couple of years and gems were proliferating—in many different release versions. At the same time, more and more teams were building big projects that needed many Ruby gems—of very specific versions in order to run.
Bundler is a library that aims to simplify the task of installing several gems, and installing very specific versions of them. Bundler reads what gems your application needs in a file called Gemfile in the root of your project. Bundler comes with a command-line tool called bundle, which we will be using throughout this book.
Bundler also has a way to group gems in various categories. An in-depth explanation of Bundler is beyond the scope of this book, but you can learn more over at http://gembundler.com/.
| support_code/11/Gemfile | |
| | source :rubygems |
| | |
| | gem 'sinatra', '1.3.2' |
| | |
| | group :development do |
| | gem 'rspec', '2.11.0' |
| | gem 'cucumber', '1.2.1' |
| | gem 'capybara', '2.0.0.beta2' |
| | end |
Run the command bundle in the root of the project to install these gems.
Once the gems are installed, we can kick the tires on Sinatra by adding a few lines to the end of lib/nice_bank.rb:
| support_code/11/lib/nice_bank.rb | |
| | require 'sinatra' |
| | get '/' do |
| | 'Welcome to our nice bank.' |
| | end |
If you run this file with the command bundle exec ruby lib/nice_bank.rb, you should see Sinatra start up a web server. You can now try hitting it from a browser at http://localhost:4567/. That’s the beginning of our user interface.
In our tests, we need to load the Capybara library and tell it where to find our web application. Change features/support/env.rb to look like this:
| support_code/11/features/support/env.rb | |
| | require File.join(File.dirname(__FILE__), '..', '..', 'lib', 'nice_bank') |
| | |
| | require 'capybara/cucumber' |
| | Capybara.app = Sinatra::Application |
| | Sinatra::Application.set :environment, :test |
We haven’t actually changed the way our tests communicate with the application, so if you run cucumber again, the scenario should still pass. Good? Time to start building our web application.