Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2018/E1878 Integrate Suggestion Detection Algorithm

2018-11-14T04:53:38Z

Kmkangut: /* Test plan */

CSC-517 Fall 2018 - E1878 Integrate suggestion detection algorithm in Expertiza Project. This Wiki page explains how we are planning to integrate the suggestion detection algorithm in Expertiza project.

==Introduction==

===Team===
# Ameya Dhavalikar
# Komal Kangutkar
# Prashanthi Kanniappan Murthy
# Vibhav Nandavaram Abbai Srivaths
===Background information===
====Expertiza====
[http://expertiza.ncsu.edu/ Expertiza] is an Open Source project based on the [http://rubyonrails.org/ Ruby on Rails] framework, supported by National Science Foundation. It is the software to create reusable learning objects through peer review. It is a project where students can submit and peer review learning objects(articles, code, websites, etc). The users of this software include students and professors. Expertiza is used by select professors and students in North Carolina State University, for example. It supports team projects, reviews of projects/teammates, submission URLs, Wiki pages and certain document types. Instructors can create projects and the students can bid for the projects. The students can be assigned teams for a particular project or they may form their own team with fellow classmates.
====Suggestion detection algorithm====
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. In the same time, we hope students could also gain knowledge from the reviews received thus improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently, we have a few classifiers that could catch useful components of review comments, such as if it contains suggestions, etc. These classifiers are already ported into web services that we’d like to be integrated into Expertiza.
====Problem statement====
#When a student submits a review, we would like to call this web service with the student’s review as the input. We would then want to tell the student whether their reviews contain suggestions or not, so they can make improvements based on the results of the webservice.
#We would also like to evaluate how much time this API is taking and if possible work a way out to improve it. We don’t want the system to be terribly slow.
==Files modified==
# app/views/response/response.html.erb
# app/views/submitted_content/_self_review.html.erb
==Design document==
==Wireframes==
====Current State====
In its current state, the student directly writes their review in segmented text boxes under instructor specified questions with no further checks about the relevance of the review they have written as shown below:

[[File:Before.jpg]]
====Expected State====
We plan to implement buttons next to each text box so that the student can check their review for volume, sentiment, suggestion, praise and criticism metrics. The rationale for including buttons right next to each text box, is so that the student gets to test only the written matter that they wish to check, and not the entirety of their review.

[[File:After.jpg]]
===Test plan===

Test: ViewSuggestionMetricsForReviewSegment
Feature: As a Student,
I want to view a popup displaying the suggestion metrics for the segment of the review I am writing
So that I can use it to improve the relevance of the review segment provided
Scenario: Display Suggestion Metrics on Empty Review Segment
Given the Student has not entered any text in the review segment
When the Student clicks the Analyze button for the segment
Then a popup will show that the user has not entered any text for suggestion metrics analysis.

Scenario: Display Suggestion Metrics on Review Segment with Text
Given the Student has entered any form of text in the review segment
When the Student clicks the Analyze button for the segment
Then a popup will show the user the results of the suggestion metrics analysis

==References==
#[http://peer-reviews-nlp.herokuapp.com/ NLP Project for suggestions algorithm]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-10T16:41:11Z

Kmkangut:

This project wrote unit tests for the menu.rb model in Expertiza. '''A test plan can be found at the bottom.'''

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. Using the given factories, we created 6 MenuItems (test1 to test6) to pass to the Menu as well as 1 Role used to test the Menu constructor.

let!(:test1) { create(:menu_item, name: "home1", parent_id: nil, seq: 1) }

admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: "", parent_id: nil, default_page_id: nil)

We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created.

allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return(items)

Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Test Plan==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb. Before the project the coverage was only

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

Below is a snapshot of the coverage of our tests. Full coverage can be found at expertiza/coverage/coverage.html. The specific coverage can be found in menu under the models tab.

[[File:Fall2018E1853Coverage.png]]

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-04T21:21:09Z

Kmkangut: /* Design */

This project wrote unit tests for the menu.rb model in Expertiza.

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. Using the given factories, we created 6 MenuItems (test1 to test6) to pass to the Menu as well as 1 Role used to test the Menu constructor.

let!(:test1) { create(:menu_item, name: "home1", parent_id: nil, seq: 1) }

admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: "", parent_id: nil, default_page_id: nil)

We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created.

allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return(items)

Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb.

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

==Test Plan==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-04T21:12:12Z

Kmkangut: /* List of all tests */

This project wrote unit tests for the menu.rb model in Expertiza.

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. We created 6 MenuItems for testing using the given factories as well as 1 Role used to test the Menu constructor. We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created. Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb.

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

==Test Plan==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-03T21:58:46Z

Kmkangut:

This project wrote unit tests for the menu.rb model in Expertiza.

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. We created 6 MenuItems for testing using the given factories as well as 1 Role used to test the Menu constructor. We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created. Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb.

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

==List of all tests==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-03T01:49:24Z

Kmkangut: /* Design */

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-03T01:40:08Z

Kmkangut: /* Design */

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-03T01:39:32Z

Kmkangut: /* Design */

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-03T01:38:43Z

Kmkangut: /* Design */

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-03T01:36:57Z

Kmkangut: /* Design */

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-03T01:34:28Z

Kmkangut: /* RSpec File */

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-03T01:33:24Z

Kmkangut:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T21:16:47Z

Kmkangut: /* Design */

This project wrote unit tests for the Menu.rb model in Expertiza.

==Project Introduction==
The menu model is used to create the top bar menu in expertiza. It does this by obtaining and organizing Menu_Items based on the current users Role. Before this project there were no unit tests for menu.rb. This project seeked to bring the unit test coverage above %90.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific test can be run by calling in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide a easy look at the work we did.

==Design==
In total we wrote 29 tests that covered all of the functions in both menu and its internal node class. We created 6 menu items for testing using the given factories as well as 1 role used to test the menu constructor. We stubbed menu item to always return an array of the 6 test items that we created. Other pieces of the code were stubbed because these pieces should be tested by menu item not menu. The double temp is used to only test the functionalities of menu.

Each method in menu.rb has at least two tests checking both a know success case and a edge case or potential failure. As an example, a detailed look at the functions to test menu#initialize is found below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below. The second line shows the change that we made. This allowed the code to be more robust and prevent noMethodErrors from nilClass. Without this change a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test uses the main covers the main use case of menu. It will be supplied with a role and will assemble a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes and contained within the menu. In this case the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use it is important it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
This 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu return a menu node. The simplest, get_item, takes the node id and returns the node object. All following functions use this to test that the correct node is returned. However to prevent circular logic, the get_item test only checks the id of the returned node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb. A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

==List of all tests==
Below is a list of the descriptions of all of the tests we wrote