CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 44: Line 44:


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


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


T2. Ensure an student could choose a topic from the assignment.
T3. Ensure an student could invite other students who are also enroll in this course.
    S1. If the invitation is sent to student who isn't enrolled in the class, the invitation should not be sent
    S2. If the invitation is sent to student who enroll in the class, the invitation should be sent
T4. Ensure an student who are invite could accept or denial.
   
T5. Ensure all teammates should have same topic.
    S1. If student accept the invitation and the student have a topic before, the topic should be dropped
    S2. If student accept the invitation and student don't have topic before, the student should have same topic as other teammates.


=References=
=References=
<references></references>
<references></references>

Revision as of 18:20, 6 November 2015

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 Ruby. It is composed of 4 main parts <ref>RSpec Official Website</ref>:

rspec-core
The spec runner, providing a rich command line program, flexible and customizable reporting, and an API to organize your code examples.

An example of running rspec file in terminal: rspec spec/model_spec.rb

rspec-expectations
Provides a readable API to express expected outcomes of a code example.
rspec-mocks
Test double framework, providing multiple types of fake objects to allow you to tightly control the environment in which your specs run.
rspec-rails
Supports using RSpec to test Ruby on Rails applications in place of Rails' built-in test framework.

Capybara

Capybara is a web-based automation test tool that simulates a real user to follow the scenarios of user stories.<ref>Capybara on GitHub</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>Introducing cucumber & capybara on YouTube</ref> Used with RSpec and Ruby on Rails (version 1.9 or later), capybara makes it easier to write integration tests. <ref>Using Capybara in Rails 3</ref> It is used on the top of an underlying web-based driver and offers a user-friendly DSL (Domain Specific Language) to describe actions executed by the underlying web driver. Such as rack::test, selenium-webdriver and capybara-webkit.<ref>The Basics of Capybara and Improving Your Tests</ref>

In this project, we use capybara with RSpec by adding the following line: require 'capybara/rspec' Then put capybara specs in spec/features.

Integration test

Integration test is a software testing definition that we combine modules then test them as one group. It is an important application testing way. It is always adapted after unit testing, we need to combine different units to test the functionalities and verify that the aggregated group could deliver its output properly. The purpose of an integration test is to verify the functionality of interface between integrated parts, also we can know the performance of the subsystems. The integration testing has two types, big bang top down and bottom up.

  • 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 an student is able to login to the system.

T2. Ensure an student could choose a topic from the assignment.

T3. Ensure an student could invite other students who are also enroll in this course.

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

T4. Ensure an student who are invite could accept or denial.

T5. Ensure all teammates should have same topic.

   S1. If student accept the invitation and the student have a topic before, the topic should be dropped
   S2. If student accept the invitation and student don't have topic before, the student should have same topic as other teammates.

References

<references></references>