CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

Purpose

This project is to perform integration testing for team creation. The testing needs to be done with the help of RSpec and Capybara. The UI procedures need to be tested are:

• Log in as a student
• Choose a available topic
• Invite one or more students as teammates
• Students who get the invition could accept or denial
• After accept the invitation, the team should form and all teammates should have same topic

Testing Tools and Concepts

RSpec

Rspec <ref>RSpec Wiki Page</ref> 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. The framework can be considered a domain-specific language (DSL) and resembles a natural language specification.In this project we will use expectation part of RSpec at most time.

RSpec-expectations<ref>RSpec expectations page</ref>

RSpec::Expectations lets you express expected outcomes on an object in an example

RSpec-rails<ref>RSpec rails page</ref>

RSpec-rails is a testing framework for Rails 3.x and 4.x..

Capybara

Capybara is a library written in the Ruby programming language which makes it easy to simulate how a user interacts with application. Capybara can talk with many different drivers which execute tests through the same clean and simple interface.<ref>Capybara page</ref>Capybara helps developer test web applications by simulating how a real user would interact with app.<ref>Capybara github page</ref>

• Using Capybara with Cucumber:

cucumber-rails gem comes with Capybara support built-in

• Using Capybara with RSpec:

Load RSpec 2.x support by adding the line: require 'capybara/rspec' .

• Using Capybara with Test::Unit:

When using Rails, add the following code in test_helper.rb file to make Capybara available in all test cases deriving from ActionDispatch::IntegrationTest .

 class ActionDispatch::IntegrationTest 
    # Make the Capybara DSL available in all integration tests 
    include Capybara::DSL 
 end 

Integration test

Integration testing<ref>Integration test</ref> is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component. A component, in this time, refers to an integrated aggregate of more than one unit. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups.

• Big Bang for Integration test

Big Bang<ref>Big Bang</ref> Integration Testing is an integration testing strategy wherein all units are linked at once, resulting in a complete system. When this type of testing strategy is adopted, it is difficult to isolate any errors found, because attention is not paid to verifying the interfaces across individual units.

• Two apporachs: Top down and Bottom up

•The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

•The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality.

Testing Plan

Based on the project requirements, the testing can be divided into the following parts:

T1. Ensure a student is able to login to the system.

T2. Ensure a student is able to choose a topic from the assignment.

T3. Ensure a student is able to form a team by inviting other students enrolled in this course.

   S1. If the invitation is sent to a student who isn't enrolled in the class, it should not be allowed.
   S2. If the invitation is sent to a student who is enrolled in the class, it should be allowed.

T4. Ensure an invitee is able to accept or reject.

T5. Ensure all teammates have the same topic.

   S1. If a student accepts the invitation and the student have a topic before, the topic should be dropped.
   S2. If a student accepts the invitation and did not have the topic before, the student should have the same topic as other teammates who accepted the invitation.

Modifying factories

Factory_girl<ref>[1]</ref> 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. The file listed below is used for modifying factories for test.

• /expertiza/spec/factories/factories.rb

Using factory_girl to modify course data.

 factory :course ,class:Course do
   name "CSC 517 Fall 2009"
   instructor_id nil
   directory_path "csc517/f09"
   info "Object-Oriented Languages and Systems"
   private true
   institutions_id nil
end

Using factory_girl to modify assignment data.

 factory :assignment ,class:Assignment do
   name "final2"
   directory_path "try" 
   submitter_count 0 
   course
   instructor_id nil
   private false
   num_reviews 0
   num_review_of_reviews 0
   num_review_of_reviewers 0
   review_questionnaire_id nil
   review_of_review_questionnaire_id nil
   teammate_review_questionnaire_id nil
   reviews_visible_to_all false
   association  :wiki_type ,:factory => :wikitype
   num_reviewers 0
   spec_location "bfbfb"
   author_feedback_questionnaire_id nil
   max_team_size 3
   ...
 end

Using factory_girl to set due date.

 factory :due_date ,class:DueDate do
   due_at  "2015-12-30 23:30:12"
   association :deadline_type, :factory => :deadline_type,strategy: :build 
   assignment { Assignment.first || association(:assignment)}   
   submission_allowed_id nil
   review_allowed_id  nil
   resubmission_allowed_id  nil
   rereview_allowed_id  nil
   review_of_review_allowed_id  nil
   round  1
   flag  false
   threshold  1
   delayed_job_id  nil
   deadline_name  nil
   description_url nil
   quiz_allowed_id nil
   teammate_review_allowed_id nil
 end

Scenario

Testing Scenario

Using Capybara to test expertize by simulating how a real user would do to form or join a team. The file listed below is used for simulating uses` behavior.

• /expertiza/spec/features/team_creation_spec.rb

Simulating one student creates a team and send an invitation to another student, and the other one accept this.

 it 'one student should send invitation and the other student should accept' do
 student=User.find_by_name("student2064")  
 role=student.role
 ApplicationController.any_instance.stub(:current_user).and_return(student)
 ApplicationController.any_instance.stub(:current_role_name).and_return('Student')
 ApplicationController.any_instance.stub(:current_role).and_return(role)
 visit '/student_task/list'
 expect(page).to have_content('final2')
 click_link 'final2'
 expect(page).to have_content('Submit or Review work for final2')
 click_link 'Signup sheet'
 expect(page).to have_content('Signup sheet for final2 assignment')
 visit '/sign_up_sheet/sign_up?assignment_id=1&id=1'
 expect(page).to have_content('Your topic(s)')
 visit '/student_task/list'
 expect(page).to have_content('final2')
 click_link 'final2'
 click_link 'Your team'
 expect(page).to have_content('final2_Team1')
 fill_in 'user_name', with:'student2065'
 click_button 'Invite'
 expect(page).to have_content('student2065') 
 student=User.find_by_name("student2065")  
 role=student.role
 ApplicationController.any_instance.stub(:current_user).and_return(student)
 ApplicationController.any_instance.stub(:current_role_name).and_return('Student')
 ApplicationController.any_instance.stub(:current_role).and_return(role)
 visit '/student_task/list'
 expect(page).to have_content('final2')
 click_link 'final2'
 click_link 'Your team'
 #expect(page).to have_content('student2064') 
 visit '/invitation/accept?inv_id=1&student_id=1&team_id=0'
 expect(page).to have_content('Team Name: final2_Team1')

References

<references></references>