CSC/ECE 517 Fall 2018/E1852 Unit Test for Participant Model: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 4: Line 4:
== Expertiza ==
== Expertiza ==
[https://expertiza.ncsu.edu/ Expertiza] is a web application designed for academia. The users of this application are instructors and students. A user as an instructor can create new assignments as well as customize existing assignments for students. Students can submit assignments, view assignment deadlines, bid for an assignment topic, create a team and peer-review learning objects (articles, code, websites, etc).
[https://expertiza.ncsu.edu/ Expertiza] is a web application designed for academia. The users of this application are instructors and students. A user as an instructor can create new assignments as well as customize existing assignments for students. Students can submit assignments, view assignment deadlines, bid for an assignment topic, create a team and peer-review learning objects (articles, code, websites, etc).
== Problem Statement ==
The Rspec file participant_spec.rb existed with test cases for name and fullname methods and provided path coverage of 36.08% for the participant model. The test cases must be written so that the path coverage is above 90%. Also, ensure that the branch coverage is as high as possible for many edge cases.
<h4>'''Files Involved'''</h4>
The files to be understood and created are:
1. app/models/participant.rb
2. spec/models/participant_spec.rb
<h4>'''Team Members'''</h4>
Students who collaborated to work on this problem statement are :
1. Reetu Shakya (rshakya@ncsu.edu)
2. Suhas Naramballi Gururaja (snaramb@ncsu.edu)
3. Tejas Gupta (tgupta4@ncsu.edu)


== Steps for Implementation ==
== Steps for Implementation ==
<h4>'''Plan of Work'''</h4>
<h4>'''Plan of Work'''</h4>


The task is to write unit test cases for testing the participant model file. The Rspec file participant_spec.rb existed with test cases for name and fullname methods and provided path coverage of 36.08% for the participant model. The procedure for project planning included :-
The task is to write unit test cases for testing the participant model file. The procedure for project planning included :-


1. Setting the Expertiza environment. We used NCSU VCL image of [CSC517, S18] Ruby on Rails/Expertiza.
1. Setting the Expertiza environment. We used NCSU VCL image of [CSC517, S18] Ruby on Rails/Expertiza.

Revision as of 02:41, 3 November 2018


Expertiza

Expertiza is a web application designed for academia. The users of this application are instructors and students. A user as an instructor can create new assignments as well as customize existing assignments for students. Students can submit assignments, view assignment deadlines, bid for an assignment topic, create a team and peer-review learning objects (articles, code, websites, etc).


Problem Statement

The Rspec file participant_spec.rb existed with test cases for name and fullname methods and provided path coverage of 36.08% for the participant model. The test cases must be written so that the path coverage is above 90%. Also, ensure that the branch coverage is as high as possible for many edge cases.


Files Involved

The files to be understood and created are:

1. app/models/participant.rb

2. spec/models/participant_spec.rb


Team Members

Students who collaborated to work on this problem statement are :

1. Reetu Shakya (rshakya@ncsu.edu)

2. Suhas Naramballi Gururaja (snaramb@ncsu.edu)

3. Tejas Gupta (tgupta4@ncsu.edu)


Steps for Implementation

Plan of Work

The task is to write unit test cases for testing the participant model file. The procedure for project planning included :-

1. Setting the Expertiza environment. We used NCSU VCL image of [CSC517, S18] Ruby on Rails/Expertiza.

2. Understand the functionality of model file in participant.rb

3. Understand the linked data attributes being used, like assignment, topic, questionnaire

4. Writing testing conditions for different functions.

Setting the Expertiza environment

1. Reserve a NCSU VCL image of [CSC517, S18] Ruby on Rails / Expertiza.

2. Connect to the reservation using SSH and enter your campus credentials for User ID and password.

3. Commands executed for setup in terminal of VCL image:

  sudo su
  gem install bundler
  exit
  git clone [Your forked Expertiza repo url]
  cd expertiza
  bash setup.sh
  (change config/database.yml, there is no MySQL password by default)
  bundle install
  rails server


Unit Testing with RSpec

Expertiza is an open source project written in Ruby, hence it uses Rspec which is a unit test framework for the Ruby programming language. To access the effectiveness of our testing, we have used SimpleCov, a code coverage analysis tool.

Test Cases

Test responses

A Participant has many ResponseMaps that map a connection between this participant as a reviewer and as a reviewee. Each ResponseMap has many Responses associated with it. When responses method is called on a Participant, it should return an array of responses associated to this Participant.

   def responses
    response_maps.map(&:response)
   end

The test below will test a participant with no corresponding mapping. Hence the result of the responses provided by the participant is a nil list

 describe '#responses' do
     it 'returns an array of responses of the participant' do
       expect(participant.responses).to eql([])
     end
end


Test name

The method name returns the name of the participants

 def name(ip_address = nil)
    self.user.name(ip_address)
end

The test below will return the name of the participant. A factory build initializes the participant with the name as student and calls the function to expect student as the outcome

 describe "#name" do
    it "returns the name of the user" do
      expect(participant.name).to eq "Student"
    end
end


A Participant is a User. When name method is called on a Participant, it should return the name of this User. Link title

Test fullname

A Participant is a User. When fullname method is called on a Participant, it should return the full name of this User.

  def fullname(ip_address = nil)
    self.user.fullname(ip_address)
end

The test is done similar to name that it expects a name which was loaded in the factory build

describe "#name" do
    it "returns the name of the user" do
      expect(participant.name).to eq "Student"
    end
end


Test delete and Forced delete

The method deletes a participant team if the participant is not associated with any team. It makes a call to force delete when the argument is true A single test case can validate the positive scenario of delete method

  def delete(force = nil)
    maps = ResponseMap.where('reviewee_id = ? or reviewer_id = ?', self.id, self.id)
    if force or (maps.blank? and self.team.nil?)
      force_delete(maps)
    else
      raise "Associations exist for this participant."
    end
end
 
 def force_delete(maps)
    maps and maps.each(&:destroy)
    if self.team and self.team.teams_users.length == 1
      self.team.delete
    elsif self.team
      self.team.teams_users.each {|teams_user| teams_user.destroy if teams_user.user_id == self.id }
    end
    self.destroy
end

The test case will attempt to delete the participant. Since the participant is not having association it will call the forced delete function and returns participant for deleting.

describe "#delete" do
    it " should remove a participant if there is no pre-existing association" do
      expect(participant.delete(true)).to eq(participant)
    end
end

Test topic_name

The method return the name of the topic which the participant has been assigned with.

 
  def topic_name
    if topic.nil? or topic.topic_name.empty?
      "<center>—</center>" # em dash
    else
      topic.topic_name
    end
end

The test will check for the error when the participant is having an assignment without a topic


describe '#topic_name' do     
     context 'when the participant has an assignment without a topic' do
       it 'returns error message' do
         expect(participant.topic_name).to eql('<center>—</center>')
       end
     end


Test able_to_review A simple method which gives the status on whether participant can review.

 def able_to_review
   can_review
 end

When able_to_review method is called on a Participant, it should return true if it can review and false otherwise.

 describe '#able_to_review' do
     it 'returns true if the participant can review' do
       expect(participant.able_to_review).to eql(true)
     end
end


When scores method is called on a Participant, it should return the total scores it received for a given number of questions.

Test get_permissions

This method returns a hash of the boolean value based on the authorization. The result of the boolean determined the ability to review , take quiz and submit.

def self.get_permissions(authorization)
    can_submit = true
    can_review = true
    can_take_quiz = true
    case authorization
    when 'reader'
      can_submit = false
    when 'reviewer'
      can_submit = false
      can_take_quiz = false
    when 'submitter'
      can_review = false
      can_take_quiz = false
    end
    {can_submit: can_submit, can_review: can_review, can_take_quiz: can_take_quiz}
end

The test case here checks whether the output hash will have the correct combination of trues and false for the authorization

  describe '.get_permissions' do
     context 'when current participant is authorized as reader' do
       it 'participant cannot submit' do
         expect(Participant.get_permissions('reader')).to eql({ :can_submit => false, :can_review => true, :can_take_quiz => true})
       end
     end

     context 'when current participant is authorized as reviewer' do
       it 'participant can only review' do
         expect(Participant.get_permissions('reviewer')).to eql({ :can_submit => false, :can_review => true, :can_take_quiz => false})
       end
     end

     context 'when current participant is authorized as submitter' do
       it 'participant can only submit' do
         expect(Participant.get_permissions('submitter')).to eql({ :can_submit => true, :can_review => false, :can_take_quiz => false})
       end
     end  
end

Test get_authorization

The method get authorization basically determies the role based on the ability to submit, review and take quiz

  def self.get_authorization(can_submit, can_review, can_take_quiz)
    authorization = 'participant'
    authorization = 'reader' if can_submit == false and can_review == true and can_take_quiz == true
    authorization = 'submitter' if can_submit == true and can_review == false and can_take_quiz == false
    authorization = 'reviewer' if can_submit == false and can_review == true and can_take_quiz == false
    authorization
end

The test cases below are designed to validate whether the method produced the 3 desired outcomes.

The first test case validates the outcome to be reader, second one check for the outcome submitter and third will check if its a reviewer

 describe ".get_authorization"  do
        it "returns authorization as reader when input is true for can_review and can_take quiz" do
                expect(Participant.get_authorization(false, true, true )).to eq('reader')
        end
        it  "returns authorization submitter when input is true only for can_submit" do
                expect(Participant.get_authorization(true, false, false)).to eq('submitter')
        end
        it  "returns authorization as reviewer when the input is true for only for can_review" do
                expect(Participant.get_authorization(false, true, false)).to eq('reviewer')
        end
end

Test sort_by_name

Participants are Users. When self.sort_by_name method is called on a Participant, it should sort a given set of participants based on their user names.

def self.sort_by_name(participants)
    users = []
    participants.each {|p| users << p.user }
    users.sort! {|a, b| a.name.downcase <=> b.name.downcase } # Sort the users based on the name
    participants.sort_by {|p| users.map(&:id).index(p.user_id) }
end

The test builds participants using factory methods and assigns name as specified. Then a function calls for sorting and the expected outcome is matched with the result

 
describe '.sort_by_name' do
     it 'sorts a set of participants based on their user names' do
       stu1 = build(:student, name: "Student1")
       stu2 = build(:student, name: "Student2")
       stu3 = build(:student, name: "Student3")
       p1 = build(:participant, user: stu1, id: 2) 
       p2 = build(:participant, user: stu2, id: 3)
       p3 = build(:participant, user: stu3, id: 1)
       participants = [ p2, p1, p3]
       
       sorted_participants = Participant.sort_by_name(participants)
       expect(Participant.sort_by_name(participants)).to match_array([p1, p2, p3])
       expect(sorted_participants.length).to eql(3)
       
       ids = []
       sorted_participants.each do |p|
         ids << p.id
       end
       expect(ids).to match_array([2, 3, 1]) 
end 

Results

We have a coverage of 77.38%.