CSC/ECE 517 Spring 2013/using fixtures with expertiza
Using Fixtures with Expertiza
Fixtures are a means with Rails to provide test data. Since Expertiza has several different types of ActiveRecord database objects, Fixtures can be a useful way to accomplish testing.
This page will give a brief overview of fixtures in rails and describe how to use them in Expertiza.
Please remember this is a Wiki page - it's not static! If there's something here that's incorrect or out of date, please help keep it up to date.
What is a Fixture?
The term "fixture" comes from the engineering world (see this definition [1]) and represents some device which can be used to test a system without having to use the system extensively. For example consider how one might test a car tire. Instead of driving a car with the tire thousands of miles, an engineer would create a test fixture which spins the tire over various simulated roads thus providing an easier means of comprehensive testing.
A software test fixture is the same concept - how can we set up a test that would normally be complex in a fixed way.
Fixtures in the context of Ruby on Rails represent test database entries. Once the test database is populated, either manual or automated testing can be done with the resultant database. Fixtures allow the tester to create the same data every time which allows for easier reproduction of bugs and quick regression testing.
How do fixtures compare to other test tools?
It's important to make a distinction between fixtures and seeds in Rails.
Fixtures represent test data. Test data will only be populated during testing and not in a production environment.
Seeds represent a base level of data which is used to start up all applications including those in production.
When is it appropriate to use fixtures?
How to use fixtures in Expertiza.
YAML language
YAML originally stood for “Yet Another Markup Language,” the authors now claim that it stands for “YAML Ain’t Markup Language.” The YAML specification can be found here. [2]
Basic YAML rules.
A pound / hash sign (‘#’) is used to begin a comment line. Only spaces, never tabs, may be used to indent YAML files. While this may seem annoying, it’s done to ensure compatibility between different environments which treat tabs in different ways.
An ActiveRecord object is defined with YAML in the following manner: objectName:
Attribute1: value Attribute2: value … Attributen: value
Using Rake to Instantiate Fixtures
Use rake.
Using the DBConsole Tool
One thing you'll notice when using fixtures is that you're manipulating the SQL database directly. In other words things won't always be going through the Model/View/Controller code structure. Because of this it can be useful to use the SQL Database console in some cases.
For example, you might want to take a look at the DB console after creating some database entries in Expertiza the 'normal' way -- by logging in as a user, creating and submitting reviews and so on. In this way you can see the details of how the various tables are related to one another which may be helpful in creating your fixtures.
To access the DB console from the linux shell type:
ruby script/dbconsole
You will see the prompt:
mysql>
From this prompt there are several interesting things to do. The most basic are looking at the various tables available, the fields in those tables, and looking at the records stored in the database.
Often things will scroll off the screen (especially if you are not using X Windows) so you will want to define a pager:
mysql>pager more PAGER set to 'more' mysql>
Now the pager 'more' will be used to filter the output from DB Console so you can read it.
First let's take a look at the tables that exist.
mysql>show tables;
Will show you a listing of tables similar to the screen shot. Compare this list of tables to your reference material such as schema.rb or other documentation.
Once we have seen all of the tables we might want to take a look at the various fields inside those tables. As you might expect this is a very straightforward command:
mysql> show fields from [your table];
Don't forget the trailing semicolon after all SQL commands. The screen shot below shows how this will look. Again this should be no great surprise if you've looked at other documentation but it's always interesting to get another view of how things fit together.
Now we can get to the business of examining the actual data. To do this we will use a database query. In SQL, database queries usually begin with SELECT. SELECT will 'select' as its name implies, some set of data from the database.
The general format of select is SELECT [one or more fields] from [table name]; This command will select all records of the specified table and show the fields you specified. For example, to select all fields from the user table you would enter:
mysql>select * from users;
This will cause lots of data to be thrown to the screen which may not be that interesting. To limit the data you can choose only certain fields, for example:
mysql>select name,handle from users;
Will print out just the names and handles of all users.
Now we may want to do some filtering. SQL SELECT statements allow qualifying the data selected. How about choosing users who have a handle defined since only some users do?
mysql>select name,handle from users where handle is not NULL;
Will print out only those users with a handle.
This only scratches the surface of what SQL can do, but it should get you thinking about how you can use DBconsole to debug your fixture definitions. For more information on SQL Select click [here:http://en.wikipedia.org/wiki/Select_%28SQL%29]