CSC/ECE 517 Fall 2015/oss E1567 APT

From Expertiza_Wiki
Jump to navigation Jump to search

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 for to verify the various access privileges for each user, import or export users.

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, , , , ,
  • The functionality for deleting a user was not working. A method has been added to delete the users.


  • The search_users method had a complicated if-else ladder. The method has now been optimized using a case statement & a call to a new method named fetch_results that returns the list of users based on role, user_id, letter, search_by parameters.

About rspec

RSpec is a behavior-driven development (BDD) framework for the Ruby programming language, inspired by JBehave. 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

   describe "#new" do
     it "Validate user instance creation with valid parameters" do
       @user.should be_an_instance_of User
     end
   end

Test Case 2

   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
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2015/oss_E1567_APT&oldid=97773"