CSC/ECE 517 Fall 2012/ch2a 2w33 pv: Difference between revisions
Line 2: | Line 2: | ||
=Introduction= | =Introduction= | ||
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories. | One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref> | ||
=Fixtures= | =Fixtures= |
Revision as of 22:18, 23 October 2012
SaaS - 5.5 - Fixtures and Factories
Introduction
One of the best parts about Ruby community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>
Fixtures
Fixtures are sample data on which all the tests run.
There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures 2. CSV fixtures 3. Single-file fixtures
YAML Fixtures
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. This file ends with the .yml extension.
The following example shows the format of a YAML fixture:
post_one: title: one description: post_one_desc category: category_one user: user_one post_two: title: two description: post_two_desc category: category_two user: user_two
CSV fixtures
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.
The following example shows the format of a CSV fixture:
title,description, category, user one, post_one_desc, category_one, user_one two, post_two_desc, category_two, user_two
Single-file fixtures
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.
The following example shows the format of a single-file fixture:
posts/post_one posts/post_two
Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:
# this will return the Hash for the fixture named post_one posts(:post_one)
Factories
A factory is an object used to create other objects. Factory objects are used in test-driven development to allow the classes to be put under test.
Also see
References
<references />