At the Forge - Testing with Rails
During the last few months, we have looked at Ruby on Rails, an open-source Web application framework written in the Ruby language meant to make Web/database development particularly easy. We already have looked at many facets of Rails development—the division of applications into model, view and controller components; subclassing ActiveRecord for automatic object/database mapping; and the use of Rails validators to ensure the integrity of data stored in the database.
Since starting to work with Rails several months ago, I have been impressed with its design and execution. Developing in Rails feels a bit different and funny at first, but you quickly can get into it, enjoying the fact that much of the tedium has been taken care of by ActiveRecord automatically.
Although Rails can reduce the amount of code we must write in our Web/database applications, it cannot reduce it to zero. And wherever there is code, there are bound to be bugs. As experienced Web/database developers know, testing these sorts of applications can be a bit tricky, because there is a disconnect between what the client sends and sees, and what actually happens with the server. It's not unusual, even today, for Web developers to debug their applications using a combination of print statements and error logs. Indeed, I am personally guilty of this on many occasions, partly out of habit and partly because this is often the best way to find problems with projects.
Managers and programmers alike know that it is cheapest and easiest to fix bugs as soon as they occur, and at an early stage of a project. But programmers often are reluctant to test their software, especially when such testing can be time consuming and tedious.
A relatively simple solution thus has emerged during the past few years, in which programmers were responsible for not only testing the software they had worked on, but also for writing the tests that would check the software in as many places as possible. Such unit testing can help ensure that each individual part of the system is robust, allowing us to depend on it when integrated into a full application.
This month, we look at the built-in Rails functionality for performing unit tests and whet our appetite for writing functional tests as well.
Everything we have seen so far might seem reasonable, but there is a danger lurking beneath the surface. If we actually go ahead and test all of our code, we are likely to end up adding, modifying and deleting data in the actual database. On a serious production system, this could be more than inconvenient, it might cause untold problems.
If you have been following along since we first began to work with Rails, you might well remember that we defined three different databases for each of the projects we have worked with. In the case of the simple Weblog application we examined the last few months, we created three databases: blog_development, blog_test and blog_production. We completely ignored the _test and _development databases, concentrating solely on the _production version. Now that we will start testing our application, we will be using the _test database. Only when we are sure that our database and application have passed the test suite will we move it over into the production system.
If you have not already done so, create the test database and load its definitions. On my system, I created a blog user for PostgreSQL and executed the following:
$/usr/local/pgsql/bin/createdb -U blog blog_test
I then loaded the database definitions that I had saved in the blog/db directory, in a file called create.sql:
$ /usr/local/pgsql/bin/psql -U blog blog_test < blog/db/create.sql
This loads the table definitions. Assuming that create.sql was identical when I did the same with the development database, I can now assume that the development and test databases are defined in the same way.
But what if we have not been so good about updating create.sql with each modification we've made to our development database? Are we then forced to compare the two database structures manually, update create.sql and then re-import the definitions?
Luckily, the answer is no. Rails comes with a short program, clone_structure_to_test, that copies the structure of the development database to the test database. Note that it copies only the structure, not the contents. To invoke it, switch to the main application directory (blog, in our case) and use the rake, or Ruby make, program, which executes the appropriate section of the Rakefile in the current directory:
$ rake clone_structure_to_test
If the blog_test database does not yet exist, or if there are other issues, you will get an error message. Otherwise, you see only basic output, as I did:
[reuven@server blog]$ rake clone_structure_to_test (in /home/reuven/blog)
I encountered some initial problems with clone_structure_to_test, with the script claiming I was not the owner of the public schema in PostgreSQL. I got around this by giving the blog database user superuser permissions, which is necessary for the cloning process to work correctly:
$ /usr/local/pgsql/bin/psql blog_test blog_development=# alter user blog createuser; ALTER USER
Now that we have our test database in place, we can start to write some tests. But where will we put them? Rails, in its typical style, already has defined a location for the tests and assumes we will follow the same convention as the author and other Rails users. This means looking in the blog/test directory, parallel with the blog/app and blog/db directories.
The blog/test directory contains four subdirectories and a single file of Ruby code, all of which are standard in a Rails application. The four subdirectories are fixtures, functional, mocks and unit, and refer to different parts of the testing mechanism that we are expected to create or modify.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- RSS Feeds
- Find new cell phone and tablet pc
4 min 51 sec ago
1 hour 33 min ago
- Automatically updating Guest Additions
2 hours 42 min ago
- I like your topic on android
3 hours 28 min ago
- Reply to comment | Linux Journal
3 hours 49 min ago
- This is the easiest tutorial
10 hours 4 min ago
- Ahh, the Koolaid.
15 hours 42 min ago
- git-annex assistant
21 hours 42 min ago
- direct cable connection
22 hours 5 min ago
- Agreed on AirDroid. With my
22 hours 15 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.