CSC/ECE 517 Fall 2015/oss E1567 APT: Difference between revisions
Line 53: | Line 53: | ||
==About rspec== | ==About rspec== | ||
[http://rspec.info/ Rspec] is a Behavior-driven development(BDD) framework for the Ruby programming language, inspired by [JBehave][http://www.jbehave.org/]. It contains its own mocking framework that is fully integrated into the framework based upon JMock. | [http://rspec.info/ Rspec] is a [https://en.wikipedia.org/wiki/Behavior-driven_development]Behavior-driven development(BDD) framework for the Ruby programming language, inspired by [JBehave][http://www.jbehave.org/]. It contains its own mocking framework that is fully integrated into the framework based upon JMock. | ||
RSpec was made in 2005 as an experiment by Steven Baker, with early contributions from Dave Astels and Aslak Hellesøy. David Chelimsky joined the team that summer, and accepted leadership of the project in 2006. David also built rspec-rails, which provided tight integration with Ruby on Rails. | RSpec was made in 2005 as an experiment by Steven Baker, with early contributions from Dave Astels and Aslak Hellesøy. David Chelimsky joined the team that summer, and accepted leadership of the project in 2006. David also built rspec-rails, which provided tight integration with Ruby on Rails. | ||
Revision as of 22:55, 6 November 2015
Introduction to Expertiza
The Expertiza project is a web application to create reusable learning objects through peer review. It supports various features such as team projects, and the submission of various documents including URLs and wiki pages. It is being extensively used across various universities for select courses. The page describes the various changes and modifications done to improve the source code of the application. The changes were accompanied by unit/functional test cases written in RSPEC to affirm no breakage in code.
Project Description
Users Controller is one of the controllers in the Expertiza Rails Application. It is used for the basic CRUD operations - creating new users, updating the details for an existing users or deleting an existing user in the system. It is also used to determine the role of particular user in the system. The role could be one of the following - Administrator, Instructor, Student, Teaching Assistant, Super-Administrator or Unregistered User. The associated model class for interacting with the user table is the User model. It is also used to verify the various access privileges for each user, import or export users. The VCL image of the project is : Expertize Image Link(http://152.46.18.164:3000/)
Classes Involved
- users_controller.rb
- user.rb
- user_spec.rb
What is Refactoring?
Code refactoring is process of changing the existing computer code to make it more maintainable, without changing the external functionality of the code. Some of the reasons for performing refactoring are:
- 1. Removal of duplicate code.
- 2. Making code more maintainable.
- 3. Dividing functionality of the class.
Modifications/Refactoring
Users_controller
The User_controller file was subject to code modifications and refactoring. The objective was to implement DRY code principles and reducing code complexity. The following were the suggested changes according to the Design document.
- 1. Initially, various functions were calling the same redirect method to redirect to the same controller. This was inimical to the code reusage principle. Following the DRY code principle, instead of calling the same link, with the action and controller as arguments, a method(redirect_to_home) was created and called from the 3 different methods namely show, index and key.
- 2. Initially, the create method in Users_contoller was being used to send emails to new users by passing strings as arguments to the mailer template. The strings were harcoded as arguments, this was modified so that varaibles were passed as parameters to the mailer template. This helped remove hardcoded code while maintaining the functionality.
- 3. Initially, in the destroy method, queries were being executed directly from the controller method, which doesn't follow Ruby on Rails code ethics. So the queries were moved to a new method destroy_user in User Model file and the method was called from within the delete method in controller.
user.rb
- Initially, the code had a very long method called
get_users_list
. It has now been broken down into several simpler methods namely,fetch_users_for_super_admin
,fetch_users_for_course
,fetch_users_for_assignment
,fetch_participants_for_courses
andadd_children
.
- The
search_users
method had a complicated if-else ladder. The method has now been optimized using a case statement. The original method also had a repetitive way of forming a search query. This has been refactored in accordance to the DRY principle into a new method namedfetch_results
that returns the list of users based onrole, user_id, letter, search_by
parameters passed to it.
About rspec
Rspec is a [1]Behavior-driven development(BDD) framework for the Ruby programming language, inspired by [JBehave][2]. It contains its own mocking framework that is fully integrated into the framework based upon JMock. RSpec was made in 2005 as an experiment by Steven Baker, with early contributions from Dave Astels and Aslak Hellesøy. David Chelimsky joined the team that summer, and accepted leadership of the project in 2006. David also built rspec-rails, which provided tight integration with Ruby on Rails.
Test Cases
Test cases were written for the user model.
Test Case 1: Testing the User Models create functionality
describe "#new" do it "Validate user instance creation with valid parameters" do @user.should be_an_instance_of User end end
Test Case 2: Testing the validations for name field in User Model
describe "#name" do it "returns the name of the user" do @user.name.should eql "abc" end it "Validate presence of name which cannot be blank" do user1 = User.new fullname: "abc bbc", email: "abcbbc@gmail.com", password: "123456789", password_confirmation: "123456789" user1.should_not be_valid end it "Validate that name is always unique" do @user0 = User.new name: "abc", fullname: "abc dbc", email: "abcdbc@gmail.com", password: "12345678", password_confirmation: "12345678" @user1 = User.new name: "abc", fullname: "abc bbc", email: "abcbbc@gmail.com", password: "123456789", password_confirmation: "123456789" @user1.should validate_uniqueness_of(:name) end end
Test Case 3: Testing the validations for fullname field in User Model
describe "#fullname" do it "returns the full name of the user" do @user.fullname.should eql "abc xyz" end end
Test Case 4: Testing the validations for email field in User Model
describe "#email" do it "returns the email of the user" do @user.email.should eql "abcxyz@gmail.com" end it "Validate presence of email which cannot be blank" do user1 = User.new name: "abc", fullname: "abc bbc", password: "123456789", password_confirmation: "123456789" user1.should_not be_valid end it "Validate the email format" do user1 = User.new name: "abc123", fullname: "abc bbc", email: "a@x", password: "123456789", password_confirmation: "123456789" user1.should_not be_valid end it "Validate the email format" do user1 = User.new name: "abc123", fullname: "abc bbc", email: "ax.com", password: "123456789", password_confirmation: "123456789" user1.should_not be_valid end it "Validate the email format" do user1 = User.new name: "abc123", fullname: "abc bbc", email: "axc", password: "123456789", password_confirmation: "123456789" user1.should_not be_valid end it "Validate the email format" do user1 = User.new name: "abc123", fullname: "abc bbc", email: "123", password: "123456789", password_confirmation: "123456789" user1.should_not be_valid end it "Validate the email format" do user1 = User.new name: "abc123", fullname: "abc bbc", email: " ", password: "123456789", password_confirmation: "123456789" user1.should_not be_valid end it "Validate the email format correctness" do user1 = User.new name: "abc123", fullname: "abc bbc", email: "a@x.com", password: "123456789", password_confirmation: "123456789" user1.should be_valid end end