Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2014/oss E1401 lmn

2014-05-05T13:18:41Z

Wemorrow: /* Future Work */ struck out things completed in final projects

==Introduction==
===Background===
Assignments in Expertiza have many components--due dates and topics, for example. Due dates and topics are objects in their own right (DueDate, SignupTopic); we need a way to have sets of due dates and topics associated with an assignment.
There are also separate forms to create and edit an Assignment and its components (Topics, Due Dates), these forms should be unified into one form for every component of an Assignment.
Also, it'd be nice if we could sort assignment due dates in order of next due.
===What Needs to be Done===
* Remove the separate New and Edit forms for assignment
* Create a form object to encapsulate the creation and editing of Assignments, Due Dates, and Topics
* Add the ability to sort Due Dates
====Classes====
* controllers/assignments_controller.rb
* controllers/due_date_controller.rb
* controllers/sign_up_sheet_controller.rb
* models/due_date.rb
* models/sign_up_topic.rb

====Objectives====
* All CUD (Create, Update, Delete) operations on Assignments, Due Dates, and Topics should be performed through an AssignmentFormObject
* Assignment, Due Date, and Topic views and controllers should be subsumed into a combined AssignmentFormObject view and controller
==Design and Implementation==
As a bit of background, form objects<ref>http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/</ref> could be thought of as a fake model that is not itself persisted but persists all its component models. The name comes from the idea that in many cases forms require information for several models at a time, rather than just one. Creating a series of forms to work with each model at a time is tedious and frustrating, both for the coder and for the end user. A form object fixes this problem by acting like a model. It can have validations, persistence strategies, and a save method that returns the object if and when it is saved, just like a model. Behind the scenes it is intelligently manipulating other models to provide this functionality transparently, encapsulating the required logic.

Our design uses one form object, AssignmentFormObject, to store data about the base Assignment model, Due Date, and Topic models associated to that Assignment. In this way we can achieve both objectives, utilizing the form object to create, update, and delete Assignments and associated Due Date and Topics without having to have separate controllers and views for each.

The form object inherits from ActiveRecord (though is not a subclass of) in order to be able to mass-assign attributes and create custom validations and Virtus<ref>https://github.com/solnic/virtus</ref> to handle attributes like a normal model. We need these custom validations because the attributes of the form object include arrays of attributes for models, something the default validations cannot handle on their own. In addition, we need to run validations on the parameters passed in for each of the models contained within the form object, again something that the default validations cannot do.

The logic behind persisting a form object is somewhat more complicated than a normal model (in which you very rarely have to override the default save operation). This is because form objects must persist several models at once, as shown below.
<nowiki>Assignment.transaction do
if @assignment.save

topics_list.each do |a|
a.assignment = @assignment
if !a.save
raise ActiveRecord::Rollback
end
end

due_dates_list.each do |a|
a.assignment = @assignment
if !a.save
raise ActiveRecord::Rollback
end
end</nowiki>
The form object starts a transaction (in order to guarantee that either everything or nothing is saved) then attempts to create (or update) the Assignment. If this succeeds, it moves on to the components of the Assignment, doing the same. If any one of these operations fails (for instance, if a topic is not able to be saved), the entire operation is rolled back, removing all of the partially saved changes and reverting to before the form object attempted to persist. In this way we make sure that the save operation is atomic like a normal model's save operation.

Because the form object can be treated like a model, writing a controller to populate views with it is just as easy as with a normal model, as shown.
<nowiki>
def create
@assignment_form_object = AssignmentFormObject.new(params)
if @assignment_form_object.save
alert("Form saved")
else
alert("Error saving form")
end
end
</nowiki>

===Changes to the View===
Basically, we have added the ability to add most of the same attributes to a new assignment as when editing an existing assignment. Previously, you could only
provide an assignment name, then you had to add due dates, etc. There are still some limitations to this process due to the complicated relationships between
models. To view the changes, navigate to "~/assignments/new". The addition of Rubrics and Review Strategies is currently not implemented for new assignments, and
this should be addressed in future works. In addition, you may only add one topic to a new assignment, then you must add more topics at the edit page.
The addition of due dates uses a partial view that is in need of refactoring. In addition some validation is necessary for date times. For submission due dates
and review due dates, please provide a date time.

===Affected Classes===
Changed existent classes
* controllers/assignments_controller.rb
* models/due_date.rb
* views/assignments/new.html.erb
* views/assignments/edit.html.erb
* views/assignments/edit/_add_signup_topics.html.erb
* views/assignments/edit/_due_dates.html.erb
* views/assignments/edit/_general.html.erb
* views/assignments/edit/_rubrics.html.erb

Added classes
* models/AssignmentFormObject.rb
* controllers/assignment_form_object_controller.rb
* helpers/assignment_form_object_helper.rb
* views/assignment_form_object/new.erb
* views/assignments/new/_add_signup_topics.html.erb
* views/assignments/new/_due_dates.html.erb
* views/assignments/new/_general.html.erb
* views/assignments/new/_late_policy.html.erb
* views/assignments/new/_review_strategy.html.erb
* views/assignments/new/_rubrics.html.erb

==Running the Project Locally==
In order to run the project locally (for feature testing or for running unit tests) please follow
these steps:
1. Clone the GitHub repository (https://github.com/losmescaleros/expertiza)
2. Run "bundle install"
3. Run "rake db:create:all"
4. If you have a database dump, run it. For this project, we used the one located here:
http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza_scrubbed_2014_03_14.sql.zip
"mysql -u root pg_development < expertiza-scrubbed.sql"
Note that this may not be the name of the zipped dump, but you can customize to your needs. You may
also need to specify your mysql password using "mysql -u root -p ..." depending on your mysql setup.
5. Run "exec rake db:migrate"
6. Run the rails server using "rails server -p 3000". You may substitute 3000 with a port number of
your choice.

===Running Tests===
For this project, we used RSpec for unit tests. These are located at spec/models/assignment_form_object_spec.rb. The tests
are primarily unit tests for the model, and it required a lot of testing of other models that were not well tested (or tested
at all) elsewhere.

==Future Work==
As with every project there are always more things to be done. With the use of a form object there are side benefits that we can take advantage of with more effort that we just didn't have time for. There are also some problematic areas we uncovered during the project that could use cleaning up. The following additional steps (or features) should be taken (or implemented) by anyone continuing with the project.
Struck out lines indicate features that have already been added in continuing work.
* <del>Ability to add multiple sign up topics from a new form</del>
* Ability to add rubric details from a new form
* Redo the due dates partial to be more readable and use rails conventions rather than JavaScript
* Redo the due dates partial in general, it is very messy and difficult to work with
* Relocate JavaScript scripts to another.js resource file rather than in-line in the html
* <del>Eliminate the need to have multiple calls to the same controller methods for every table entry for due dates on the edit pages</del>

==References==
<references/>

CSC/ECE 517 Spring 2014/oss E1401 lmn

2014-04-01T00:36:21Z

Wemorrow: /* Design and Implementation */ Added more detail to the explanation of the form object implementation

==Introduction==
===Background===
Assignments in Expertiza have many components--due dates and topics, for example. Due dates and topics are objects in their own right (DueDate, SignupTopic); we need a way to have sets of due dates and topics associated with an assignment.
There are also separate forms to create and edit an Assignment and its components (Topics, Due Dates), these forms should be unified into one form for every component of an Assignment.
Also, it'd be nice if we could sort assignment due dates in order of next due.
===What Needs to be Done===
* Remove the separate New and Edit forms for assignment
* Create a form object to encapsulate the creation and editing of Assignments, Due Dates, and Topics
* Add the ability to sort Due Dates
====Classes====
* controllers/assignments_controller.rb
* controllers/due_date_controller.rb
* controllers/sign_up_sheet_controller.rb
* models/due_date.rb
* models/sign_up_topic.rb

====Objectives====
* All CUD (Create, Update, Delete) operations on Assignments, Due Dates, and Topics should be performed through an AssignmentFormObject
* Assignment, Due Date, and Topic views and controllers should be subsumed into a combined AssignmentFormObject view and controller
==Design and Implementation==
As a bit of background, form objects<ref>http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/</ref> could be thought of as a fake model that is not itself persisted but persists all its component models. The name comes from the idea that in many cases forms require information for several models at a time, rather than just one. Creating a series of forms to work with each model at a time is tedious and frustrating, both for the coder and for the end user. A form object fixes this problem by acting like a model. It can have validations, persistence strategies, and a save method that returns the object if and when it is saved, just like a model. Behind the scenes it is intelligently manipulating other models to provide this functionality transparently, encapsulating the required logic.

Our design uses one form object, AssignmentFormObject, to store data about the base Assignment model, Due Date, and Topic models associated to that Assignment. In this way we can achieve both objectives, utilizing the form object to create, update, and delete Assignments and associated Due Date and Topics without having to have separate controllers and views for each.

The form object inherits from ActiveRecord (though is not a subclass of) in order to be able to mass-assign attributes and create custom validations and Virtus<ref>https://github.com/solnic/virtus</ref> to handle attributes like a normal model. We need these custom validations because the attributes of the form object include arrays of attributes for models, something the default validations cannot handle on their own. In addition, we need to run validations on the parameters passed in for each of the models contained within the form object, again something that the default validations cannot do.

The logic behind persisting a form object is somewhat more complicated than a normal model (in which you very rarely have to override the default save operation). This is because form objects must persist several models at once, as shown below.
<nowiki>Assignment.transaction do
if @assignment.save

topics_list.each do |a|
a.assignment = @assignment
if !a.save
raise ActiveRecord::Rollback
end
end

due_dates_list.each do |a|
a.assignment = @assignment
if !a.save
raise ActiveRecord::Rollback
end
end</nowiki>
The form object starts a transaction (in order to guarantee that either everything or nothing is saved) then attempts to create (or update) the Assignment. If this succeeds, it moves on to the components of the Assignment, doing the same. If any one of these operations fails (for instance, if a topic is not able to be saved), the entire operation is rolled back, removing all of the partially saved changes and reverting to before the form object attempted to persist. In this way we make sure that the save operation is atomic like a normal model's save operation.

Because the form object can be treated like a model, writing a controller to populate views with it is just as easy as with a normal model, as shown.
<nowiki>
def create
@assignment_form_object = AssignmentFormObject.new(params)
if @assignment_form_object.save
alert("Form saved")
else
alert("Error saving form")
end
end
</nowiki>
===Affected Classes===
Changed existent classes
* controllers/assignments_controller.rb
* models/due_date.rb
* views/assignments/new.html.erb
* views/assignments/edit.html.erb
* views/assignments/edit/_add_signup_topics.html.erb
* views/assignments/edit/_due_dates.html.erb
* views/assignments/edit/_general.html.erb
* views/assignments/edit/_rubrics.html.erb

Added classes
* models/AssignmentFormObject.rb
* controllers/assignment_form_object_controller.rb
* helpers/assignment_form_object_helper.rb
* views/assignment_form_object/new.erb
* views/assignments/new/_add_signup_topics.html.erb
* views/assignments/new/_due_dates.html.erb
* views/assignments/new/_general.html.erb
* views/assignments/new/_late_policy.html.erb
* views/assignments/new/_review_strategy.html.erb
* views/assignments/new/_rubrics.html.erb

==Future Work==
As with every project there are always more things to be done. With the use of a form object there are side benefits that we can take advantage of with more effort that we just didn't have time for. There are also some problematic areas we uncovered during the project that could use cleaning up. The following additional steps (or features) should be taken (or implemented) by anyone continuing with the project.
* Ability to add multiple sign up topics from a new form
* Ability to add rubric details from a new form
* Redo the due dates partial to be more readable and use rails conventions rather than JavaScript
* Redo the due dates partial in general, it is very messy and difficult to work with
* Relocate JavaScript scripts to another.js resource file rather than in-line in the html
* Eliminate the need to have multiple calls to the same controller methods for every table entry for due dates on the edit pages
==References==
<references/>

CSC/ECE 517 Spring 2014/oss E1401 lmn

2014-03-31T17:18:17Z

Wemorrow: Added references, changed the format of the linked references to agree with the references tag

CSC/ECE 517 Spring 2014/oss E1401 lmn

2014-03-31T17:12:42Z

Wemorrow: /* Future Work */ filled in with Mitchell's list of suggestions for future work

CSC/ECE 517 Spring 2014/oss E1401 lmn

2014-03-31T14:57:34Z

Wemorrow: Reorganized classes, updated design and implementation

CSC/ECE 517 Spring 2014/oss E1401 lmn

2014-03-31T12:06:44Z

Wemorrow: /* Classes */

CSC/ECE 517 Spring 2014/oss E1401 lmn

2014-03-31T00:06:50Z

Wemorrow: Initial writeup

CSC/ECE 517 Spring 2014

2014-03-30T22:07:51Z

Wemorrow:

*[[CSC/ECE_517_Fall_2012/example_page]]
*[[CSC/ECE 517 Spring 2014/ch1a 1e rm]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1h jg ]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1b np]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1f mj]]
*[[CSC/ECE 517 Spring 2014/ch1a 1d mm]]
*[[CSC/ECE 517 Spring 2014/ch1a 1c yj]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1l m]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1m bm]]
*[[CSC/ECE 517 Spring 2014/ch1a 1p fy]]
*[[CSC/ECE 517 Spring 2014/oss E1401 lmn]]
*[[CSC/ECE 517 Spring 2014/oss E1402 mmb]]
*[[CSC/ECE 517 Spring 2014/oss E1404 mnp]]
*[[CSC/ECE 517 Spring 2014/oss E1406 st]]

CSC/ECE 517 Spring 2014/ch1a 1k wm

2014-02-21T20:59:05Z

Wemorrow: /* Example */ added some narrative about why DRY should hold for fixtures

=Factory Girl=
[https://docs.google.com/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Assignment Spec]
==Background==
From Factory Girl's Ruby Toolbox page<ref>https://www.ruby-toolbox.com/projects/factory_girl</ref>:
<blockquote>factory_girl provides a framework and DSL for defining and using factories - less error-prone, more explicit, and all-around easier to work with than fixtures.</blockquote>
Also from the Factory Girl's github page<ref>https://github.com/thoughtbot/factory_girl</ref>:
<blockquote>factory_girl is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.</blockquote>

Factory Girl's purpose is to expedite good testing by creating test fixtures for the developer, eliminating the need to create large fixtures by hand. There are two versions, one for use with regular Ruby (factory_girl) and one for use with Ruby on Rails (factory_girl_rails<ref>https://github.com/thoughtbot/factory_girl_rails</ref>)

'''Test fixtures''' are used to create an application state through which you can test code.<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref> In some cases, the application state you need to build is very simple. For example, in unit testing you are testing very small pieces of code, the state that you need to set up is very small (typically one or two instances of a single model class). In other cases the application state may be complicated and the data handled very large, in which case the fixture will also be very large. Large fixtures could be used in performance testing in order to load the system up and tax its resources.

==Generic Examples==
All examples taken from the github project<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>
===Factories===
Factories are the basic unit of Factory Girl, they wrap up a constructor into a single method call that can be used in multiple test fixtures.
A factory looks pretty similar to a normal constructor but can be used multiple times without having to specify any parameters, as shown below.
<nowiki>FactoryGirl.define do
factory :user do
first_name "John"
last_name "Doe"
admin false
end
end</nowiki>
The above creates a factory for class User (inferred by Factory Girl from the name of the factory) that can then be called in many different ways.
You can also define factories using specific classes, not only inferred from the name of the factory, as below (in the same word as the above example).
<nowiki>FactoryGirl.define do
factory :admin, class: User do
first_name "Admin"
last_name "User"
admin true
end
end</nowiki>
===Using Factories===
You can use factories in a variety of ways, as shown. You can also overwrite predefined attributes on the fly by passing in a hash of attributes and values.
<nowiki># Returns a User instance that's not saved
user = build(:user)

# Returns a saved User instance
user = create(:user)

# Returns a hash of attributes that can be used to build a User instance
attrs = attributes_for(:user)

# Returns an object with all defined attributes stubbed out
stub = build_stubbed(:user)

# Passing a block to any of the methods above will yield the return object
create(:user) do |user|
user.posts.create(attributes_for(:post))
end

# Build a User instance and override the first_name property
user = build(:user, first_name: "Joe")
user.first_name
# => "Joe"</nowiki>

===Aliasing===
You can utilize aliases to make somewhat more specialized factories out of existing factories, as shown.
<nowiki>factory :user, aliases: [:author, :commenter] do
first_name "John"
last_name "Doe"
date_of_birth { 18.years.ago }
end

factory :post do
author
# instead of
# association :author, factory: :user
title "How to read a book effectively"
body "There are five steps involved."
end

factory :comment do
commenter
# instead of
# association :commenter, factory: :user
body "Great article!"
end
</nowiki>
The above code creates a factory called '''user''' and then uses that factory to add users as attributes of post and comment with a different name (author and commenter).

===Lazy, Dependent, and Transient Attributes===
Attributes need not be statically defined. There are several other ways to define attributes of factories, all termed '''lazy''' attributes because they acquire a value after the object has been instantianted.
The simplest case of lazy attributes is the simple lazy attribute, determined by a block rather than given as a static value.
<nowiki>factory :user do
# ...
activation_code { User.generate_activation_code }
date_of_birth { 21.years.ago }
end</nowiki>

Dependent attributes are lazy attributes that use the values of other attributes in the factory to determine their value.
<nowiki>factory :user do
first_name "Joe"
last_name "Blow"
email { "#{first_name}.#{last_name}@example.com".downcase }
end

create(:user, last_name: "Doe").email
# => "joe.doe@example.com"
</nowiki>

Finally, transient attributes allow you to further modify factories and prevent repetition of code, in a way passing arguments to the factory creation function.
<nowiki>factory :user do
ignore do
rockstar true
upcased false
end

name { "John Doe#{" - Rockstar" if rockstar}" }
email { "#{name.downcase}@example.com" }

after(:create) do |user, evaluator|
user.name.upcase! if evaluator.upcased
end
end

create(:user, upcased: true).name
#=> "JOHN DOE - ROCKSTAR"
</nowiki>

===Further Reading===
Factory Girl contains far more than can be expressed in so verbose a fashion in a summary page, so be sure to read the entirety of the [https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md Getting Started] guide.
This guide goes through all of the above and more, in detail, with code examples.

==Using with Ruby on Rails==
As mentioned earlier, Factory Girl can be used in Ruby on Rails through the factory_girl_rails gem. All of the same benefits apply, including those not mentioned above.

===Example===
A typical test scenario is benchmarking the time a sort takes to complete on a random assortment of objects. A stock Rake test fixture implementation might look something like the following:
<nowiki> person1:
id: 1
name: Bob
dob: 10-11-1990

person2:
id: 2
name: George
dob: 9-8-1990

person3:
id: 3
name: Stanley
dob: 1-9-1990</nowiki>

This could get tedious with more than 3 values, so you could use ERb (Embedded Ruby)
<nowiki> <% for i in 1..1000 %>
fix_<%= i %>:
id: <%= i %>
name: guy_<%= 1 %>
dob: <%= Date.today.strftime("%Y-%m-%d") %>
<% end %></nowiki>

However, this is harder to maintain and is not very DRY-friendly: it's very repetitious and you must copy the entire block any time you need to put 1000 users into a fixture. Not only that, but if you did copy the code block, if at any point the class changes you'd have to go back and change all the places you copied that code. Instead, we could use Factory Girl and expedite the process, also making it more DRY while we're at it (using some Factory Girl features not shown above)!
<nowiki>FactoryGirl.define do
sequence :email do |n|
"person#{n}@example.com"
end

sequence :id do |n|
#{n}
end

sequence :dob do |n|
(20.years.ago)+(Random.rand(20).months)#give random DOB from 20 years ago + 0..20 months
end

factory :user do
id
first_name "John"
last_name "Doe"
email
dob
end
end

built_users_2500 = build_list(:user, 2500) #make 2500 users with unique email addresses and id's and random DOB
built_users_10 = build_list(:user, 10) #make 10 more users
</nowiki>

By abstracting away the creation of unique IDs for our users and giving us a factory through which to create a list of users, we need not worry about the implementation of making a group of users in our fixtures. If at any time the class changes, we need only change the file that has the factory in it, all calls to the factory remain unchanged.

==References==
<references />

CSC/ECE 517 Spring 2014/ch1a 1k wm

2014-02-21T19:58:37Z

Wemorrow: /* Background */ updated the wording of the definition and explanation of test fixtures

=Factory Girl=
[https://docs.google.com/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Assignment Spec]
==Background==
From Factory Girl's Ruby Toolbox page<ref>https://www.ruby-toolbox.com/projects/factory_girl</ref>:
<blockquote>factory_girl provides a framework and DSL for defining and using factories - less error-prone, more explicit, and all-around easier to work with than fixtures.</blockquote>
Also from the Factory Girl's github page<ref>https://github.com/thoughtbot/factory_girl</ref>:
<blockquote>factory_girl is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.</blockquote>

Factory Girl's purpose is to expedite good testing by creating test fixtures for the developer, eliminating the need to create large fixtures by hand. There are two versions, one for use with regular Ruby (factory_girl) and one for use with Ruby on Rails (factory_girl_rails<ref>https://github.com/thoughtbot/factory_girl_rails</ref>)

'''Test fixtures''' are used to create an application state through which you can test code.<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref> In some cases, the application state you need to build is very simple. For example, in unit testing you are testing very small pieces of code, the state that you need to set up is very small (typically one or two instances of a single model class). In other cases the application state may be complicated and the data handled very large, in which case the fixture will also be very large. Large fixtures could be used in performance testing in order to load the system up and tax its resources.

==Generic Examples==
All examples taken from the github project<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>
===Factories===
Factories are the basic unit of Factory Girl, they wrap up a constructor into a single method call that can be used in multiple test fixtures.
A factory looks pretty similar to a normal constructor but can be used multiple times without having to specify any parameters, as shown below.
<nowiki>FactoryGirl.define do
factory :user do
first_name "John"
last_name "Doe"
admin false
end
end</nowiki>
The above creates a factory for class User (inferred by Factory Girl from the name of the factory) that can then be called in many different ways.
You can also define factories using specific classes, not only inferred from the name of the factory, as below (in the same word as the above example).
<nowiki>FactoryGirl.define do
factory :admin, class: User do
first_name "Admin"
last_name "User"
admin true
end
end</nowiki>
===Using Factories===
You can use factories in a variety of ways, as shown. You can also overwrite predefined attributes on the fly by passing in a hash of attributes and values.
<nowiki># Returns a User instance that's not saved
user = build(:user)

# Returns a saved User instance
user = create(:user)

# Returns a hash of attributes that can be used to build a User instance
attrs = attributes_for(:user)

# Returns an object with all defined attributes stubbed out
stub = build_stubbed(:user)

# Passing a block to any of the methods above will yield the return object
create(:user) do |user|
user.posts.create(attributes_for(:post))
end

# Build a User instance and override the first_name property
user = build(:user, first_name: "Joe")
user.first_name
# => "Joe"</nowiki>

===Aliasing===
You can utilize aliases to make somewhat more specialized factories out of existing factories, as shown.
<nowiki>factory :user, aliases: [:author, :commenter] do
first_name "John"
last_name "Doe"
date_of_birth { 18.years.ago }
end

factory :post do
author
# instead of
# association :author, factory: :user
title "How to read a book effectively"
body "There are five steps involved."
end

factory :comment do
commenter
# instead of
# association :commenter, factory: :user
body "Great article!"
end
</nowiki>
The above code creates a factory called '''user''' and then uses that factory to add users as attributes of post and comment with a different name (author and commenter).

===Lazy, Dependent, and Transient Attributes===
Attributes need not be statically defined. There are several other ways to define attributes of factories, all termed '''lazy''' attributes because they acquire a value after the object has been instantianted.
The simplest case of lazy attributes is the simple lazy attribute, determined by a block rather than given as a static value.
<nowiki>factory :user do
# ...
activation_code { User.generate_activation_code }
date_of_birth { 21.years.ago }
end</nowiki>

Dependent attributes are lazy attributes that use the values of other attributes in the factory to determine their value.
<nowiki>factory :user do
first_name "Joe"
last_name "Blow"
email { "#{first_name}.#{last_name}@example.com".downcase }
end

create(:user, last_name: "Doe").email
# => "joe.doe@example.com"
</nowiki>

Finally, transient attributes allow you to further modify factories and prevent repetition of code, in a way passing arguments to the factory creation function.
<nowiki>factory :user do
ignore do
rockstar true
upcased false
end

name { "John Doe#{" - Rockstar" if rockstar}" }
email { "#{name.downcase}@example.com" }

after(:create) do |user, evaluator|
user.name.upcase! if evaluator.upcased
end
end

create(:user, upcased: true).name
#=> "JOHN DOE - ROCKSTAR"
</nowiki>

===Further Reading===
Factory Girl contains far more than can be expressed in so verbose a fashion in a summary page, so be sure to read the entirety of the [https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md Getting Started] guide.
This guide goes through all of the above and more, in detail, with code examples.

==Using with Ruby on Rails==
As mentioned earlier, Factory Girl can be used in Ruby on Rails through the factory_girl_rails gem. All of the same benefits apply, including those not mentioned above.

===Example===
A typical test scenario is benchmarking the time a sort takes to complete on a random assortment of objects. A stock Rake test fixture implementation might look something like the following:
<nowiki> person1:
id: 1
name: Bob
dob: 10-11-1990

person2:
id: 2
name: George
dob: 9-8-1990

person3:
id: 3
name: Stanley
dob: 1-9-1990</nowiki>

This could get tedious with more than 3 values, so you could use ERb (Embedded Ruby)
<nowiki> <% for i in 1..1000 %>
fix_<%= i %>:
id: <%= i %>
name: guy_<%= 1 %>
dob: <%= Date.today.strftime("%Y-%m-%d") %>
<% end %></nowiki>

However, this is harder to maintain and is not very DRY-friendly. Instead, we could use Factory Girl and expedite the process, also making it more DRY while we're at it (using some Factory Girl features not shown above)!
<nowiki>FactoryGirl.define do
sequence :email do |n|
"person#{n}@example.com"
end

sequence :id do |n|
#{n}
end

sequence :dob do |n|
(20.years.ago)+(Random.rand(20).months)#give random DOB from 20 years ago + 0..20 months
end

factory :user do
id
first_name "John"
last_name "Doe"
email
dob
end
end

built_users_2500 = build_list(:user, 2500) #make 2500 users with unique email addresses and id's and random DOB
built_users_10 = build_list(:user, 10) #make 10 more users
</nowiki>

==References==
<references />

CSC/ECE 517 Spring 2014/ch1a 1k wm

2014-02-15T01:02:58Z

Wemorrow: /* Factory Girl */

=Factory Girl=
[https://docs.google.com/document/d/1XzVu0zEuk7LP4smGZV9lRpSx5-wri6oClpUAmGYPN44/edit# Assignment Spec]
==Background==
From Factory Girl's Ruby Toolbox page<ref>https://www.ruby-toolbox.com/projects/factory_girl</ref>:
<blockquote>factory_girl provides a framework and DSL for defining and using factories - less error-prone, more explicit, and all-around easier to work with than fixtures.</blockquote>
Also from the Factory Girl's github page<ref>https://github.com/thoughtbot/factory_girl</ref>:
<blockquote>factory_girl is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.</blockquote>

Factory Girl's purpose is to expedite good testing by creating test fixtures for the developer, eliminating the need to create large fixtures by hand. There are two versions, one for use with regular Ruby (factory_girl) and one for use with Ruby on Rails (factory_girl_rails<ref>https://github.com/thoughtbot/factory_girl_rails</ref>)

'''Test fixtures''' are used to create an application state through which you can test code.<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref> This can be as simple as constructing two objects with which to perform a comparison (testing the comparison operator) or as complicated as can be imagined.

==Generic Examples==
All examples taken from the github project<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>
===Factories===
Factories are the basic unit of Factory Girl, they wrap up a constructor into a single method call that can be used in multiple test fixtures.
A factory looks pretty similar to a normal constructor but can be used multiple times without having to specify any parameters, as shown below.
<nowiki>FactoryGirl.define do
factory :user do
first_name "John"
last_name "Doe"
admin false
end
end</nowiki>
The above creates a factory for class User (inferred by Factory Girl from the name of the factory) that can then be called in many different ways.
You can also define factories using specific classes, not only inferred from the name of the factory, as below (in the same word as the above example).
<nowiki>FactoryGirl.define do
factory :admin, class: User do
first_name "Admin"
last_name "User"
admin true
end
end</nowiki>
===Using Factories===
You can use factories in a variety of ways, as shown. You can also overwrite predefined attributes on the fly by passing in a hash of attributes and values.
<nowiki># Returns a User instance that's not saved
user = build(:user)

# Returns a saved User instance
user = create(:user)

# Returns a hash of attributes that can be used to build a User instance
attrs = attributes_for(:user)

# Returns an object with all defined attributes stubbed out
stub = build_stubbed(:user)

# Passing a block to any of the methods above will yield the return object
create(:user) do |user|
user.posts.create(attributes_for(:post))
end

# Build a User instance and override the first_name property
user = build(:user, first_name: "Joe")
user.first_name
# => "Joe"</nowiki>

===Aliasing===
You can utilize aliases to make somewhat more specialized factories out of existing factories, as shown.
<nowiki>factory :user, aliases: [:author, :commenter] do
first_name "John"
last_name "Doe"
date_of_birth { 18.years.ago }
end

factory :post do
author
# instead of
# association :author, factory: :user
title "How to read a book effectively"
body "There are five steps involved."
end

factory :comment do
commenter
# instead of
# association :commenter, factory: :user
body "Great article!"
end
</nowiki>
The above code creates a factory called '''user''' and then uses that factory to add users as attributes of post and comment with a different name (author and commenter).

===Lazy, Dependent, and Transient Attributes===
Attributes need not be statically defined. There are several other ways to define attributes of factories, all termed '''lazy''' attributes because they acquire a value after the object has been instantianted.
The simplest case of lazy attributes is the simple lazy attribute, determined by a block rather than given as a static value.
<nowiki>factory :user do
# ...
activation_code { User.generate_activation_code }
date_of_birth { 21.years.ago }
end</nowiki>

Dependent attributes are lazy attributes that use the values of other attributes in the factory to determine their value.
<nowiki>factory :user do
first_name "Joe"
last_name "Blow"
email { "#{first_name}.#{last_name}@example.com".downcase }
end

create(:user, last_name: "Doe").email
# => "joe.doe@example.com"
</nowiki>

Finally, transient attributes allow you to further modify factories and prevent repetition of code, in a way passing arguments to the factory creation function.
<nowiki>factory :user do
ignore do
rockstar true
upcased false
end

name { "John Doe#{" - Rockstar" if rockstar}" }
email { "#{name.downcase}@example.com" }

after(:create) do |user, evaluator|
user.name.upcase! if evaluator.upcased
end
end

create(:user, upcased: true).name
#=> "JOHN DOE - ROCKSTAR"
</nowiki>

===Further Reading===
Factory Girl contains far more than can be expressed in so verbose a fashion in a summary page, so be sure to read the entirety of the [https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md Getting Started] guide.
This guide goes through all of the above and more, in detail, with code examples.

==Using with Ruby on Rails==
As mentioned earlier, Factory Girl can be used in Ruby on Rails through the factory_girl_rails gem. All of the same benefits apply, including those not mentioned above.

===Example===
A typical test scenario is benchmarking the time a sort takes to complete on a random assortment of objects. A stock Rake test fixture implementation might look something like the following:
<nowiki> person1:
id: 1
name: Bob
dob: 10-11-1990

person2:
id: 2
name: George
dob: 9-8-1990

person3:
id: 3
name: Stanley
dob: 1-9-1990</nowiki>

This could get tedious with more than 3 values, so you could use ERb (Embedded Ruby)
<nowiki> <% for i in 1..1000 %>
fix_<%= i %>:
id: <%= i %>
name: guy_<%= 1 %>
dob: <%= Date.today.strftime("%Y-%m-%d") %>
<% end %></nowiki>

However, this is harder to maintain and is not very DRY-friendly. Instead, we could use Factory Girl and expedite the process, also making it more DRY while we're at it (using some Factory Girl features not shown above)!
<nowiki>FactoryGirl.define do
sequence :email do |n|
"person#{n}@example.com"
end

sequence :id do |n|
#{n}
end

sequence :dob do |n|
(20.years.ago)+(Random.rand(20).months)#give random DOB from 20 years ago + 0..20 months
end

factory :user do
id
first_name "John"
last_name "Doe"
email
dob
end
end

built_users_2500 = build_list(:user, 2500) #make 2500 users with unique email addresses and id's and random DOB
built_users_10 = build_list(:user, 10) #make 10 more users
</nowiki>

==References==
<references />

CSC/ECE 517 Spring 2014/ch1a 1k wm

2014-02-15T01:01:15Z

Wemorrow: Page creation

=Factory Girl=
==Background==
From Factory Girl's Ruby Toolbox page<ref>https://www.ruby-toolbox.com/projects/factory_girl</ref>:
<blockquote>factory_girl provides a framework and DSL for defining and using factories - less error-prone, more explicit, and all-around easier to work with than fixtures.</blockquote>
Also from the Factory Girl's github page<ref>https://github.com/thoughtbot/factory_girl</ref>:
<blockquote>factory_girl is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.</blockquote>

Factory Girl's purpose is to expedite good testing by creating test fixtures for the developer, eliminating the need to create large fixtures by hand. There are two versions, one for use with regular Ruby (factory_girl) and one for use with Ruby on Rails (factory_girl_rails<ref>https://github.com/thoughtbot/factory_girl_rails</ref>)

'''Test fixtures''' are used to create an application state through which you can test code.<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref> This can be as simple as constructing two objects with which to perform a comparison (testing the comparison operator) or as complicated as can be imagined.

==Generic Examples==
All examples taken from the github project<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>
===Factories===
Factories are the basic unit of Factory Girl, they wrap up a constructor into a single method call that can be used in multiple test fixtures.
A factory looks pretty similar to a normal constructor but can be used multiple times without having to specify any parameters, as shown below.
<nowiki>FactoryGirl.define do
factory :user do
first_name "John"
last_name "Doe"
admin false
end
end</nowiki>
The above creates a factory for class User (inferred by Factory Girl from the name of the factory) that can then be called in many different ways.
You can also define factories using specific classes, not only inferred from the name of the factory, as below (in the same word as the above example).
<nowiki>FactoryGirl.define do
factory :admin, class: User do
first_name "Admin"
last_name "User"
admin true
end
end</nowiki>
===Using Factories===
You can use factories in a variety of ways, as shown. You can also overwrite predefined attributes on the fly by passing in a hash of attributes and values.
<nowiki># Returns a User instance that's not saved
user = build(:user)

# Returns a saved User instance
user = create(:user)

# Returns a hash of attributes that can be used to build a User instance
attrs = attributes_for(:user)

# Returns an object with all defined attributes stubbed out
stub = build_stubbed(:user)

# Passing a block to any of the methods above will yield the return object
create(:user) do |user|
user.posts.create(attributes_for(:post))
end

# Build a User instance and override the first_name property
user = build(:user, first_name: "Joe")
user.first_name
# => "Joe"</nowiki>

===Aliasing===
You can utilize aliases to make somewhat more specialized factories out of existing factories, as shown.
<nowiki>factory :user, aliases: [:author, :commenter] do
first_name "John"
last_name "Doe"
date_of_birth { 18.years.ago }
end

factory :post do
author
# instead of
# association :author, factory: :user
title "How to read a book effectively"
body "There are five steps involved."
end

factory :comment do
commenter
# instead of
# association :commenter, factory: :user
body "Great article!"
end
</nowiki>
The above code creates a factory called '''user''' and then uses that factory to add users as attributes of post and comment with a different name (author and commenter).

===Lazy, Dependent, and Transient Attributes===
Attributes need not be statically defined. There are several other ways to define attributes of factories, all termed '''lazy''' attributes because they acquire a value after the object has been instantianted.
The simplest case of lazy attributes is the simple lazy attribute, determined by a block rather than given as a static value.
<nowiki>factory :user do
# ...
activation_code { User.generate_activation_code }
date_of_birth { 21.years.ago }
end</nowiki>

Dependent attributes are lazy attributes that use the values of other attributes in the factory to determine their value.
<nowiki>factory :user do
first_name "Joe"
last_name "Blow"
email { "#{first_name}.#{last_name}@example.com".downcase }
end

create(:user, last_name: "Doe").email
# => "joe.doe@example.com"
</nowiki>

Finally, transient attributes allow you to further modify factories and prevent repetition of code, in a way passing arguments to the factory creation function.
<nowiki>factory :user do
ignore do
rockstar true
upcased false
end

name { "John Doe#{" - Rockstar" if rockstar}" }
email { "#{name.downcase}@example.com" }

after(:create) do |user, evaluator|
user.name.upcase! if evaluator.upcased
end
end

create(:user, upcased: true).name
#=> "JOHN DOE - ROCKSTAR"
</nowiki>

===Further Reading===
Factory Girl contains far more than can be expressed in so verbose a fashion in a summary page, so be sure to read the entirety of the [https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md Getting Started] guide.
This guide goes through all of the above and more, in detail, with code examples.

==Using with Ruby on Rails==
As mentioned earlier, Factory Girl can be used in Ruby on Rails through the factory_girl_rails gem. All of the same benefits apply, including those not mentioned above.

===Example===
A typical test scenario is benchmarking the time a sort takes to complete on a random assortment of objects. A stock Rake test fixture implementation might look something like the following:
<nowiki> person1:
id: 1
name: Bob
dob: 10-11-1990

person2:
id: 2
name: George
dob: 9-8-1990

person3:
id: 3
name: Stanley
dob: 1-9-1990</nowiki>

This could get tedious with more than 3 values, so you could use ERb (Embedded Ruby)
<nowiki> <% for i in 1..1000 %>
fix_<%= i %>:
id: <%= i %>
name: guy_<%= 1 %>
dob: <%= Date.today.strftime("%Y-%m-%d") %>
<% end %></nowiki>

However, this is harder to maintain and is not very DRY-friendly. Instead, we could use Factory Girl and expedite the process, also making it more DRY while we're at it (using some Factory Girl features not shown above)!
<nowiki>FactoryGirl.define do
sequence :email do |n|
"person#{n}@example.com"
end

sequence :id do |n|
#{n}
end

sequence :dob do |n|
(20.years.ago)+(Random.rand(20).months)#give random DOB from 20 years ago + 0..20 months
end

factory :user do
id
first_name "John"
last_name "Doe"
email
dob
end
end

built_users_2500 = build_list(:user, 2500) #make 2500 users with unique email addresses and id's and random DOB
built_users_10 = build_list(:user, 10) #make 10 more users
</nowiki>

==References==
<references />