Expertiza_Wiki - User contributions [en]

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

2015-11-07T15:58:52Z

Bjhaver: /* Testing */

== '''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>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a Behavior Driven Development (BDD) framework for Ruby. It is composed of 4 main parts <ref>[http://rspec.info/ 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: <code>rspec spec/model_spec.rb </code>

; 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>[https://github.com/jnicklas/capybara Capybara on GitHub]</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>[https://www.youtube.com/watch?v=p7ZcZNuZ0aw 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>[http://techiferous.com/2010/04/using-capybara-in-rails-3/ 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 <code>rack::test</code>, <code>selenium-webdriver</code> and <code>capybara-webkit</code>.<ref>[http://www.sitepoint.com/basics-capybara-improving-tests/ The Basics of Capybara and Improving Your Tests]</ref>

In this project, we use capybara with RSpec by adding the following line:
<code> require 'capybara/rspec' </code>
Then put capybara specs in <code>spec/features</code>.
=== 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>[https://en.wikipedia.org/wiki/Integration_testing/ 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.

=References=
<references></references>

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

2015-11-07T15:57:49Z

Bjhaver: /* Testing */

== '''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>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a Behavior Driven Development (BDD) framework for Ruby. It is composed of 4 main parts <ref>[http://rspec.info/ 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: <code>rspec spec/model_spec.rb </code>

; 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>[https://github.com/jnicklas/capybara Capybara on GitHub]</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>[https://www.youtube.com/watch?v=p7ZcZNuZ0aw 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>[http://techiferous.com/2010/04/using-capybara-in-rails-3/ 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 <code>rack::test</code>, <code>selenium-webdriver</code> and <code>capybara-webkit</code>.<ref>[http://www.sitepoint.com/basics-capybara-improving-tests/ The Basics of Capybara and Improving Your Tests]</ref>

In this project, we use capybara with RSpec by adding the following line:
<code> require 'capybara/rspec' </code>
Then put capybara specs in <code>spec/features</code>.
=== 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>[https://en.wikipedia.org/wiki/Integration_testing/ 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 could choose a topic from the assignment.

T3. Ensure a student can 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 can 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.

=References=
<references></references>

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

2015-11-07T15:57:04Z

Bjhaver: /* Testing */

== '''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>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a Behavior Driven Development (BDD) framework for Ruby. It is composed of 4 main parts <ref>[http://rspec.info/ 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: <code>rspec spec/model_spec.rb </code>

; 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>[https://github.com/jnicklas/capybara Capybara on GitHub]</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>[https://www.youtube.com/watch?v=p7ZcZNuZ0aw 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>[http://techiferous.com/2010/04/using-capybara-in-rails-3/ 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 <code>rack::test</code>, <code>selenium-webdriver</code> and <code>capybara-webkit</code>.<ref>[http://www.sitepoint.com/basics-capybara-improving-tests/ The Basics of Capybara and Improving Your Tests]</ref>

In this project, we use capybara with RSpec by adding the following line:
<code> require 'capybara/rspec' </code>
Then put capybara specs in <code>spec/features</code>.
=== 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>[https://en.wikipedia.org/wiki/Integration_testing/ 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 could choose a topic from the assignment.

T3. Ensure a student can 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 can 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 same topic as other teammates who accepted the invitation.

=References=
<references></references>

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

2015-11-07T15:51:40Z

Bjhaver: /* Testing */

== '''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>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a Behavior Driven Development (BDD) framework for Ruby. It is composed of 4 main parts <ref>[http://rspec.info/ 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: <code>rspec spec/model_spec.rb </code>

; 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>[https://github.com/jnicklas/capybara Capybara on GitHub]</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>[https://www.youtube.com/watch?v=p7ZcZNuZ0aw 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>[http://techiferous.com/2010/04/using-capybara-in-rails-3/ 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 <code>rack::test</code>, <code>selenium-webdriver</code> and <code>capybara-webkit</code>.<ref>[http://www.sitepoint.com/basics-capybara-improving-tests/ The Basics of Capybara and Improving Your Tests]</ref>

In this project, we use capybara with RSpec by adding the following line:
<code> require 'capybara/rspec' </code>
Then put capybara specs in <code>spec/features</code>.
=== 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>[https://en.wikipedia.org/wiki/Integration_testing/ 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 could choose a topic from the assignment.

T3. Ensure a 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>

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

2015-11-06T17:29:11Z

Bjhaver:

== '''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:

== '''Background''' ==

=== RSpec ===
Rspec <ref>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a Behavior Driven Development (BDD) framework for Ruby. It is composed of 4 main parts <ref>[http://rspec.info/ 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: <code>rspec spec/model_spec.rb </code>

; 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>[https://github.com/jnicklas/capybara Capybara on GitHub]</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>[https://www.youtube.com/watch?v=p7ZcZNuZ0aw 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>[http://techiferous.com/2010/04/using-capybara-in-rails-3/ 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 <code>rack::test</code>, <code>selenium-webdriver</code> and <code>capybara-webkit</code>.<ref>[http://www.sitepoint.com/basics-capybara-improving-tests/ The Basics of Capybara and Improving Your Tests]</ref>

In this project, we use capybara with RSpec by adding the following line:
<code> require 'capybara/rspec' </code>
Then put capybara specs in <code>spec/features</code>.
=== 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>[https://en.wikipedia.org/wiki/Integration_testing/ Integration testing on Wikipedia]</ref>

== '''Testing''' ==

=References=
<references></references>

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

2015-11-06T17:28:34Z

Bjhaver:

== '''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
* Create a course
* View scores for an assignment
* View review scores (“review report”)
* View author-feedback scores
* Create an assignment
** 2 rounds of review
** Has no topics / has topics
** Staggered-deadline assignments

== '''Background''' ==

=== RSpec ===
Rspec <ref>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a Behavior Driven Development (BDD) framework for Ruby. It is composed of 4 main parts <ref>[http://rspec.info/ 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: <code>rspec spec/model_spec.rb </code>

; 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>[https://github.com/jnicklas/capybara Capybara on GitHub]</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>[https://www.youtube.com/watch?v=p7ZcZNuZ0aw 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>[http://techiferous.com/2010/04/using-capybara-in-rails-3/ 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 <code>rack::test</code>, <code>selenium-webdriver</code> and <code>capybara-webkit</code>.<ref>[http://www.sitepoint.com/basics-capybara-improving-tests/ The Basics of Capybara and Improving Your Tests]</ref>

In this project, we use capybara with RSpec by adding the following line:
<code> require 'capybara/rspec' </code>
Then put capybara specs in <code>spec/features</code>.
=== 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>[https://en.wikipedia.org/wiki/Integration_testing/ Integration testing on Wikipedia]</ref>

== '''Testing''' ==

=References=
<references></references>

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

2015-11-06T17:20:34Z

Bjhaver:

== '''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
* Create a course
* View scores for an assignment
* View review scores (“review report”)
* View author-feedback scores
* Create an assignment
** 2 rounds of review
** Has no topics / has topics
** Staggered-deadline assignments

== '''Background''' ==

=== RSpec ===
Rspec <ref>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a Behavior Driven Development (BDD) framework for Ruby. It is composed of 4 main parts <ref>[http://rspec.info/ 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: <code>rspec spec/model_spec.rb </code>

; 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>[https://github.com/jnicklas/capybara Capybara on GitHub]</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>[https://www.youtube.com/watch?v=p7ZcZNuZ0aw 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>[http://techiferous.com/2010/04/using-capybara-in-rails-3/ 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 <code>rack::test</code>, <code>selenium-webdriver</code> and <code>capybara-webkit</code>.<ref>[http://www.sitepoint.com/basics-capybara-improving-tests/ The Basics of Capybara and Improving Your Tests]</ref>

In this project, we use capybara with rspec by adding the following line:
<code> require 'capybara/rspec' </code>
Then put capybara specs in <code>spec/features</code>.
=== 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 integration test is to verify the functionality of interface between interacted parts, also we can know 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>[https://en.wikipedia.org/wiki/Integration_testing/ Integration testing on Wikipedia]</ref>

== '''Testing''' ==

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

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

T2. Ensure an instuctor is able to create a course.

T3. Ensure that the score of a certain assignment can be viewed.

T4. Ensure to view the score of a review.

T5. Ensure to view the score of an author feedback.

T6. Ensure to create an assignment which has two rounds of review, has a topic or does not has a topic, and has a staggered-deadline.

=References=
<references></references>

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

2015-11-06T17:17:12Z

Bjhaver:

== '''Purpose''' ==
This project is to create integration tests for the instructor interface of Expertiza. The UI procedures need to be tested are:
* Log in
* Create a course
* View scores for an assignment
* View review scores (“review report”)
* View author-feedback scores
* Create an assignment
** 2 rounds of review
** Has no topics / has topics
** Staggered-deadline assignments

== '''Background''' ==

=== RSpec ===
Rspec <ref>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a Behavior Driven Development (BDD) framework for Ruby. It is composed of 4 main parts <ref>[http://rspec.info/ 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: <code>rspec spec/model_spec.rb </code>

; 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>[https://github.com/jnicklas/capybara Capybara on GitHub]</ref> It could interact with app to receive pages, parse the HTML and submit forms as a user would.<ref>[https://www.youtube.com/watch?v=p7ZcZNuZ0aw 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>[http://techiferous.com/2010/04/using-capybara-in-rails-3/ 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 <code>rack::test</code>, <code>selenium-webdriver</code> and <code>capybara-webkit</code>.<ref>[http://www.sitepoint.com/basics-capybara-improving-tests/ The Basics of Capybara and Improving Your Tests]</ref>

In this project, we use capybara with rspec by adding the following line:
<code> require 'capybara/rspec' </code>
Then put capybara specs in <code>spec/features</code>.
=== 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 integration test is to verify the functionality of interface between interacted parts, also we can know 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>[https://en.wikipedia.org/wiki/Integration_testing/ Integration testing on Wikipedia]</ref>

== '''Testing''' ==

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

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

T2. Ensure an instuctor is able to create a course.

T3. Ensure that the score of a certain assignment can be viewed.

T4. Ensure to view the score of a review.

T5. Ensure to view the score of an author feedback.

T6. Ensure to create an assignment which has two rounds of review, has a topic or does not has a topic, and has a staggered-deadline.

=References=
<references></references>

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

2015-11-06T17:07:47Z

Bjhaver: Created page with "Intro == Assignment == === Description === This project aims at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to..."

Intro

== Assignment ==

=== Description ===
This project aims at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to the authors for any doubts related to the assignments during peer reviewing.

=== Purpose ===
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review. As a result, reviewers will end up submitting the empty or incomplete review.

=== Scope ===
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.

Following tasks would be incorporated in the project:
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.

== Design ==

=== Discussion of Resolution ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Mock-Ups ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Use Cases ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Suggestions for Future Improvements ==

* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
* A purging script can be developed which will clear all the interaction records every semester.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015

2015-11-06T17:04:43Z

Bjhaver: /* Final Project Design Document */

==Writing Assignment 2==
*[[CSC/ECE_517_Fall_2015/sample_page]]
*[[CSC/ECE_517_Fall_2015/ossE1558BGJ]]
*[[CSC/ECE 517 Fall 2015/oss/M1502/AAAASS]]
*[[CSC/ECE 517 Fall 2015/oss/M1503/IntegrateXMLParser]]
*[[CSC/ECE_517_Fall_2015/ossE1568BZHXJS]]
*[[CSC/ECE_517_Fall_2015/ossE1572VGA]]
*[[CSC/ECE_517_Fall_2015/oss_E1573_sap]]
*[[CSC/ECE 517 Fall 2015/oss E1559 rrz]]
*[[CSC/ECE 517 Fall 2015/oss E1570 avr]]
*[[CSC/ECE 517 Fall 2015/oss E1556 CHM]]
*[[CSC/ECE 517 Fall 2015/oss M1504 JJD]]
*[[CSC/ECE 517 Fall 2015/oss E1562 APS]]
*[[CSC/ECE 517 Fall 2015/oss M1501 GSN]]
*[[CSC/ECE 517 Fall 2015/oss M1501 GSN]]
*[[CSC/ECE 517 Fall 2015/oss E1550 KMM]]
*[[CSC/ECE 517 Fall 2015/oss E1551 RGS]]
*[[CSC/ECE 517 Fall 2015/oss E1555 GMR]]
*[[CSC/ECE 517 Fall 2015/oss E1552 NFR]]
*[[CSC/ECE 517 Fall 2015/oss E1565 AAJ]]
*[[CSC/ECE 517 Fall 2015/oss E1561 WZL]]
*[[CSC/ECE 517 Fall 2015/oss E1553 AAJ]]
*[[CSC/ECE 517 Fall 2015/oss E1554 AAR]]
*[[CSC/ECE 517 Fall 2015/oss E1569 JNR]]
*[[CSC/ECE 517 Fall 2015/oss E1560 PSV]]
*[[CSC/ECE 517 Fall 2015/oss M1505 MSV]]
*[[CSC/ECE 517 Fall 2015/oss E1557 GXM]]
*[[CSC/ECE 517 Fall 2015/oss E1566 ARB]]
*[[CSC/ECE 517 Fall 2015/oss E1567 APT]]
*[[CSC/ECE 517 Fall 2015/oss E1574 BKS]]
*[[CSC/ECE 517 Fall 2015/ossA1550RAN]]

==Final Project Design Document==
*[[CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump]]
*[[CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer]]
*[[CSC/ECE 517 Fall 2015 E1582 Create integration tests for the instructor interface using capybara and rspec]]
*[[CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)]]
*[[CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation]]

User:Bjhaver

2015-11-06T16:55:22Z

Bjhaver: E1590 Integration testing for Team creation

E1590 Integration testing for Team creation