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

Background

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>[1]</ref>Capybara helps developer test web applications by simulating how a real user would interact with app.<ref>[2]</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 is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.

• Big Bang

In this type, since all the application is combined with all major usage modules. So we test them under usage model testing, which means we can simulate the users' acts under testing environment. When doing this, we can test if all the expected components is got when we actually do the same way under production environment. It is an effective way to test the functionalities and got better coverage since we are creating the realistic scenarios. It will make sure the application can have proper output when a user does the same input.

• Top down and Bottom up

Top down and bottom up is another type of integration testing. For top down, we test the top integrated module firstly and test the ranch of it again and again, then we can test all the related modules finally. For Bottom up way, we test the most basic module at first and check the module that containing this basic module. The advantage of it is that we can find the bug easier because we will not miss any branch that we use. However, it is time consuming in this way.<ref>Integration testing on Wikipedia</ref>

Testing

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.

Scenario

References

<references></references>