Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T01:54:24Z

Srajend: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

This method is used to anonymize the usernames in the views for demo purposes.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


3. set_anonymized_view


3.1 "The method should add the session ip to the list of anonymized ip's and redirect to the previous page "


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This is tested by the same test for index"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== Test Result ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T01:53:37Z

Srajend: /* Methods */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

3. set_anonymized_view

This method is used to anonymize the usernames in the views for demo purposes.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


3. set_anonymized_view


3.1 "The method should add the session ip to the list of anonymized ip's and redirect to the previous page "


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== Test Result ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-25T01:52:14Z

Srajend: /* Test Plan */

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request3.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index


1.1 "If the user is student, we check if proper redirection is taking place" 
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"


2. auto_complete_for_user_name


2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"


3. set_anonymized_view


3.1 "The method should add the session ip to the list of anonymized ip's and redirect to the previous page "


4. list


4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"


5. list_pending_requested


5.1 "check if it will render users/list_pending_requested page"


6. show_selection


6.1 "check if the user is nil, will the page redirect to users/list page" 
6.2 "check if the user is not available for editing, will it redirect to users/list page" 
6.3 "check if the user is available for editing, will it render users/show page"


7. show


7.1 "check if the user id is nil or if the role is student and session id equals to id, will it redirect to home" 
7.2 "if the user is valid, check the return value"


8. new


8.1 "check if this will render users/new page"


9. request_new


9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."


10. create


10.1 "Is the name new? If yes, good. Otherwise, register the user by email address." 
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"


11. create_requested_user_record


11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution." 
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."


12. create_approved_user


12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject." 
12.2 "is the status Approved or Rejected?" 
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail" 
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."


13. edit


13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."


14. update


14.1 "When user is updated successfully, it shows correct flash and redirects to users/show page. 
14.2 "When user is not updated successfully, it redirects to users/edit page."


15. destroy


15.1 "When user is not deleted successfully, it shows an error and redirects to users/list page."
(This also covers the condition that user is deleted successfully.)


16. keys


16.1 "When params[:id] is not nil, @private_key gets correct value." 
16.2 "When params[:id] is nil, it redirects to /tree_display/drill page."


== Test Result ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-09T02:29:42Z

Srajend:

This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
== Project Statement ==

=== Introduction ===

users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.

All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.

=== Files Involved ===

Newly-created file:

spec/users_controller_spec.rb

Tested file:

app/controllers/users_controller.rb

Related view files:

app/views/users/edit.html.erb

app/views/users/keys.html.erb

app/views/users/list.html.erb

app/views/users/list_pending_requested.erb

app/views/users/new.html.erb

app/views/users/request_new.html.erb

app/views/users/show.html.erb

=== Team Members ===

1. Sandeep Rajendran(srajend@ncsu.edu)

2. Xiao Ma(xma21@ncsu.edu)

3. Zekun Zhang(zzhang56@ncsu.edu)

4. Zhiyu Chen(zchen45@ncsu.edu)

== Functionality of the Controller ==
=== Table ===

Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)

1. name

2. crypted_password - It is the password after encrypting.

3. password_salt - It stores the information of the encryption for the password verification.

4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.

5. fullname

6. email

7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.

8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.

9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.

10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.

11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.

12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.

13. is_new_user

14. master_permission_granted

15. handle

16. digital_certificate

17. persistence_token

18. timezonepref

19. public_key

20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.

21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered

=== Methods ===
1. index

This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.

2. auto_complete_for_user_name

The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.

4. list

This method calls the get_user_list method in the user model which returns a list of users according to the role of the user that calls the method. This list is stored in the @users instance variable which is used by the view.

5. list_pending_requested

This method is called to show all the requests which need to be reviewed. It first obtains all the request users and the roles. Then It will show those request_users who is under review and their details with a selection window--"status" which is used to determine if this request will be approved or rejected.

6. show_selection

This method is used to show the users. It first detects if this user is valid or not. if this user is nil, it will redirect to the "list" page. If this user is valid, it will call the get_role method to get the role information of this user. and then use the role information to determine if this user is available for editing. For users available for editing, this method will render show "page", otherwise, this method will redirect to "list" page. In summary, this method will direct to "show" page, when the user is able to be edited, otherwise, it will go to "list" page.

7. show

This method is used to show the details of a user. It first detect is the user is valid. There two condition for an invalid user: 1) the id of user is nil; 2) current user role is not student and the session id doesn't equal to the user id. Otherwise this user is valid. For a valid user, it will show his/her detailed information including name, email, password, prefs, institution and self_introduction.

8. new

This method is called when method create is used to create a new user.

[[File:Request_frame.png]]

(This image will be helpful for the next 4 methods)

9. request_new

This method is called when a TA or instructor requests an Expertiza account. To register to use the Expertiza, one needs to be either a course TA or Instructor and then sends a request to Expertiza administrator to get approved. This function only serves TAs and instructors, and the students account will be created by instructors or TAs.

10. create

This method is called when the user wants to create accounts.

11. create_requested_user_record

This method is called after the guest sending a request for the account to Expertiza administrator. After the guest sending a request for the account using request_new method, this method will store the request in the database and list all the requests on the pending_request page waiting for the administrator to operate.

12. create_approved_user

This method is called when the Expertiza administrator deals with the guests' pending requests. By this method, the administrator can approve or decline the pending requests.

13. edit

"resources :users" in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.

Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].

14. update

"resources :users" in routing rule makes update action get called when the form in user's edit page is submitted.

This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.

15. destroy

"resources :users" in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.

When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.

16. keys

"get :keys" under the collection block of "resources :users" will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.

When this method is called, if no current user or current user is a student but is not the user stored in session, it will redirect to home page of the user stored in session. Otherwise generate_keys (a method of user model) will be called on the current user and the return value will be assigned to an instance variable @private_key defined in UsersController.

== Test Plan ==

This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done.
1. Download and set the Expertiza environment
2. Determine which methods should be tested
3. Define all the conditions needed to be tested for each method

The methods have already been introduced on above, here are the test plan for each method:

1. index

<pre>
1.1 "If the user is student, we check if proper redirection is taking place"
1.2 "Else, the appropriate list of users should be rendered according to the role of the current user"
</pre>

2. auto_complete_for_user_name

<pre>
2.1 "The page should render suggestions only of those user names that are similar to the one being typed and not all user names"
</pre>

4. list

<pre>
4.1 "The @users instance variable should contain all the users that are permitted to be viewed by the current user. This will be checked for all the different user types"
</pre>

9. request_new

<pre>
9.1 "Here isn't any conditional sentence. So only need to check whether the return value is expected."
</pre>

10. create

<pre>
10.1 "Is the name new? If yes, good. Otherwise, register the user by email address."
10.2 "Is the user's information valid? If yes, good. Otherwise, fail"
</pre>

11. create_requested_user_record

<pre>
11.1 "does the user belong to any institution? If yes, good. Otherwise, set a new institution."
11.2 "is the user already existed and valid? If both yes, good. If the user already exist, send notification. If the information is not valid, fail."
</pre>

12. create_approved_user

<pre>
12.1 "does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject."
12.2 "is the status Approved or Rejected?"
12.2.1 "if the status is Approved, is the information valid? if yes, good. Otherwise fail"
12.2.2 "if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request."
</pre>

13. edit

<pre>
13.1 "Here isn't any conditional sentence, so we just need to check if it renders users#edit page."
</pre>

14. update

<pre>
14.1 "If the attributes of users are successfully updated, check whether it shows the correct flash and redirects to users#show page after updating."
14.2 "If the attributes of users are not successfully updated, check whether it renders users#edit page."
</pre>

== References ==

CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb

2018-04-06T16:58:25Z

Srajend:

CSC/ECE 517 Spring 2018/E1813 Test Menu Items Model

2018-04-03T01:03:09Z

Srajend:

This wiki page is for the description of changes made under E1813 OSS Assignment for Spring 2018, CSC/ECE 517.

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Test Driven-Development===
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,but more recently has created more general interest in its own right.
The TDD sequence can be can be summarized in following steps.

1.Add a Test:

TDD begins by writing succinct test cases to test each of the features. This is opposite to traditional software development paradigm where code is written first and then test cases are later written to test the application.

2.Run all tests and see if the new test fails:

This step validates that the test harness is working correctly, shows that the new test does not pass without requiring new code because the required behavior already exists, and it rules out the possibility that the new test is flawed and will always pass. The new test should fail for the expected reason. This step increases the developer's confidence in the new test.

3.Write the code:

The next step is to write the minimum amount of code that causes the test case to pass.

4.Run tests:

In this steps the test cases are run.If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

5. Refactor code:

In this step, refactoring of code is performed by following good design principles like removal of duplicate code, improving the readability and maintainability of the code.

6. Repeat:

Starting with another new test,the next step is to repeat the cycle to push the functionality forward.

Advantages of using TDD:
*Narrowing Problem Focus
*Tidier Code
*Not worrying about dependencies
*Easier refactoring
*Better Test coverage and fewer bugs

===Unit Testing===
[https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code are tested to catch errors early in the development process. For a model it involves testing the interface and on how it responds to commands and queries from outside. Model testing is bounded to the functionality of only the model under test and doesn't test how its collaborating models get affected based on this query.

Unit Testing provides several benefits which can be summarized in the below points.

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. It is to test all class and instance methods used in this file. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are :

1. Harish Pullagurla ( hpullag@ncsu.edu )

2. Kalyan Ghosh (kghosh@ncsu.edu)

3. Sandeep Rajendran(srajend@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
The steps that we followed to set up the Expertiza environment are as follows:

1. In the first step we installed the Virtual Box free software from Oracle in our local machines.

2. Then we downloaded the lightweight Lubuntu image file and imported the image file into the virtualbox ubuntu environment.

3. Then we executed the following set up commands in the terminal to set up the application in our local machine.

Setup commands:

*sudo su
*gem install bundler
*exit
*git clone [Your forked Expertiza repo url]
*cd expertiza
*bash setup.sh
(change config/database.yml, there is no MySQL password by default)
*bundle install
*rails server

After successfully setting up the environment, we could LogIn to the Expertiza application using our credentials.

To navigate to the menu_item.rb file we performed the following steps.

1. Open terminal inside the virtual environment.

2. Navigate to the model folder of the application by typing the following command in the terminal.

cd/expetiza/app/models

[[File:Menu_item.jpg]]

The menu_item_spec.rb test file is present in this directory

expertiza/spec/models/

The menu_item_spec.rb is the main file where test cases have been written.

To navigate to the menu_item.rb file we performed the following steps.

1. Open terminal inside the virtual environment.

2. Navigate to the model folder of the application by typing the following command in the terminal.

cd/expertiza/spec/models

[[File:Menu_item_spec.jpg]]

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Sample Views====

Sample view of menu bar item for instructor ans student are shown below.

[[File:E1813 memu bar instructor.png]]

View from a student account.
[[File:E1813menu bar expertiza.png]]

====Table ====
Table corresponding to menu item model has the following attributes:-

1. Name

2. Label :- These attributes talk about the labeling being given to the attributes

3. Parent id :- It tells about under which attribute does this particular attribute fall . If it is set has <null> it is the base category.

4. Sequence id :- It gives sequence numbering for determining the way the attributes are ordered within a parent.

5. controller action id

6. Content page id :- These attributes tell, to which direction/ page, this selection directs the user onto.

====Methods in the Model====

Different instance methods and class methods exist in this models . Brief description of each of them are : -

1. find_or_create_by_name(params) :- Class Method
This method finds or creates a new entry with the given name obtained in params

2. delete :- Instance Method
This methods deletes the entry and all the child entries ( entries having the same parent id ) lined to it

3. above :- Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below :- Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id) :- Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id) :- Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission :- Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "MenuItem.new()" method, giving different values for each of the test inputs to cover the required testing conditions.

before(:each) do
@test1 = MenuItem.new(name: "home1", parent_id: nil, seq: 1, controller_action_id: nil, content_page_id: nil, label: "newlabel")
@test1.save
end

The above is an example entry used for creating objects. 6 such test objects were created with entries giving combinations of parent_id and sequence numbers.

Before each test, all the objects are created, which is done using "before(:each)" key word.
Also several objects of 'ControllerAction' and 'ContentPage' had to be created for testing one of the methods which acted based on those values.

=== Testing Conditions ===
A total of 16 testing conditions were required to be performed for testing all the functions in menu items model file.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:

In this we had write unit test cases to test if the method returned a menu_item corresponding to a name.
Here we expect that if the method find_or_create_by_name() is passed the parameter "home", then it should return a value equal to "home"

2. #delete:

In this test cases were written to check if the method deletes current menu items and all child menu items.
In this case, if the parent menu item is deleted, all its child record should should be deleted.
For our specific case, the parent and its 3 child menu_items are expected to be deleted.

3. #above:

Test cases were written to check if the below conditions are satisfied:

3.1 "When current menu item has parent_id, the method returns the first parent menu item by querying the parent_id and current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test4, the method should return a value equal to the active record test3.

3.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test5, the method should return a value equal to the active record test1.

4. #below:

Test cases were written to check if the below conditions are satisfied:

4.1 "When current menu item has parent_id,the method returns the first parent menu item by querying the parent_id and current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test3, the method should return a value equal to the active record test4

4.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test1, the method should return a value equal to the active record test5.

5. .repack:

Test cases were written to check if the below conditions are satisfied:

5.1 "When current menu item has repack_id, the method finds all menus items with parent_id equal to repack_id and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value 1,
then, it will repack the sequence ids and returns the list of repacked seq_ids.
5.2 "When current menu item does not have repack_id, the method finds all menus items with parent_id null and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value Null,
it will match all the values with parent_id = Null and returns the list of repacked seq_ids.

6. .next_seq:

Test cases were written to check if the below conditions are satisfied:

6.1 "When parent_id is bigger than 0, the method selects corresponding menu items with inputted parent_id and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value 1, the method should return a value equal to 5.

6.2 "When parent_id is smaller than or equal to 0, the method selects corresponding menu items with parent_id null and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value nil, the method should return a value equal to 6.

7. .items_for_permissions:

Test cases were written to check if the below conditions are satisfied:

7.1 "When inputted variable (permission_ids) is nil and when the controller_action_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.2 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.3 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
the method should return an empty list.
7.4 "When inputted variable (permission_ids) is not nil and when the controller_action_id of current item is bigger than 0 and when perms exists,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records
which satisfy the condition.
7.5 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0, and when perms exists,
the method returns corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records which satisfy the condition.
7.6 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as a parameter,
the method should return an empty list.

The screenshot of the actual menu_item_spec.rb file is give below and the pull request can be found here[https://github.com/expertiza/expertiza/pull/1152]:
[[File:Menu item spec code.jpg]]

== Test Runs ==

A screenshot of the tests passing is shown here
[[File:RunTest.jpg]]

Screencast of a test run can be found here[https://www.youtube.com/watch?v=Acywhk_IjDY&feature=youtu.be]

== Conclusion and Learning Outcomes ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application.
In our case we did not have to install SimpleCov explicitly since it was already installed earlier.
After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder.
This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers, Models, Helpers in the app directory.

The learning outcomes after performing this project can be summarized in the following points:

1. We got an hands on experience about how to write tests following the Test Driven Development approach.

2. We learned about how to write units tests for models and controllers in RSpec.

3. We also learned how to understand the functionality of an already developed application.For our case, before writing the test cases for the menu_items.rb we had the understand how different models interacted with each other and how each action by different users would make changes in the database schema.

4. We also gained a better understanding about how different tables, columns of a large applications in structured in the database schema.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/sandeep993/expertiza/tree/menu_item_branch GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018/E1813 Test Menu Items Model

2018-04-03T00:17:28Z

Srajend:

This wiki page is for the description of changes made under E1813 OSS Assignment for Spring 2018, CSC/ECE 517.

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Test Driven-Development===
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,but more recently has created more general interest in its own right.
The TDD sequence can be can be summarized in following steps.

1.Add a Test:

TDD begins by writing succinct test cases to test each of the features. This is opposite to traditional software development paradigm where code is written first and then test cases are later written to test the application.

2.Run all tests and see if the new test fails:

This step validates that the test harness is working correctly, shows that the new test does not pass without requiring new code because the required behavior already exists, and it rules out the possibility that the new test is flawed and will always pass. The new test should fail for the expected reason. This step increases the developer's confidence in the new test.

3.Write the code:

The next step is to write the minimum amount of code that causes the test case to pass.

4.Run tests:

In this steps the test cases are run.If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

5. Refactor code:

In this step, refactoring of code is performed by following good design principles like removal of duplicate code, improving the readability and maintainability of the code.

6. Repeat:

Starting with another new test,the next step is to repeat the cycle to push the functionality forward.

Advantages of using TDD:
*Narrowing Problem Focus
*Tidier Code
*Not worrying about dependencies
*Easier refactoring
*Better Test coverage and fewer bugs

===Unit Testing===
[https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code are tested to catch errors early in the development process. For a model it involves testing the interface and on how it responds to commands and queries from outside. Model testing is bounded to the functionality of only the model under test and doesn't test how its collaborating models get affected based on this query.

Unit Testing provides several benefits which can be summarized in the below points.

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. It is to test all class and instance methods used in this file. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are :

1. Harish Pullagurla ( hpullag@ncsu.edu )

2. Kalyan Ghosh (kghosh@ncsu.edu)

3. Sandeep Rajendran(srajend@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
The steps that we followed to set up the Expertiza environment are as follows:

1. In the first step we installed the Virtual Box free software from Oracle in our local machines.

2. Then we downloaded the lightweight Lubuntu image file and imported the image file into the virtualbox ubuntu environment.

3. Then we executed the following set up commands in the terminal to set up the application in our local machine.

Setup commands:

*sudo su
*gem install bundler
*exit
*git clone [Your forked Expertiza repo url]
*cd expertiza
*bash setup.sh
(change config/database.yml, there is no MySQL password by default)
*bundle install
*rails server

After successfully setting up the environment, we could LogIn to the Expertiza application using our credentials.

To navigate to the menu_item.rb file we performed the following steps.

1. Open terminal inside the virtual environment.

2. Navigate to the model folder of the application by typing the following command in the terminal.

cd/expetiza/app/models

[[File:Menu_item.jpg]]

The menu_item_spec.rb test file is present in this directory

expertiza/spec/models/

The menu_item_spec.rb is the main file where test cases have been written.

To navigate to the menu_item.rb file we performed the following steps.

1. Open terminal inside the virtual environment.

2. Navigate to the model folder of the application by typing the following command in the terminal.

cd/expertiza/spec/models

[[File:Menu_item_spec.jpg]]

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Sample Views====

Sample view of menu bar item for instructor ans student are shown below.

[[File:E1813 memu bar instructor.png]]

View from a student account.
[[File:E1813menu bar expertiza.png]]

====Table ====
Table corresponding to menu item model has the following attributes:-

1. Name

2. Label :- These attributes talk about the labeling being given to the attributes

3. Parent id :- It tells about under which attribute does this particular attribute fall . If it is set has <null> it is the base category.

4. Sequence id :- It gives sequence numbering for determining the way the attributes are ordered within a parent.

5. controller action id

6. Content page id :- These attributes tell, to which direction/ page, this selection directs the user onto.

====Methods in the Model====

Different instance methods and class methods exist in this models . Brief description of each of them are : -

1. find_or_create_by_name(params) :- Class Method
This method finds or creates a new entry with the given name obtained in params

2. delete :- Instance Method
This methods deletes the entry and all the child entries ( entries having the same parent id ) lined to it

3. above :- Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below :- Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id) :- Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id) :- Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission :- Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "MenuItem.new()" method, giving different values for each of the test inputs to cover the required testing conditions.

before(:each) do
@test1 = MenuItem.new(name: "home1", parent_id: nil, seq: 1, controller_action_id: nil, content_page_id: nil, label: "newlabel")
@test1.save
end

The above is an example entry used for creating objects. 6 such test objects were created with entries giving combinations of parent_id and sequence numbers.

Before each test, all the objects are created, which is done using "before(:each)" key word.
Also several objects of 'ControllerAction' and 'ContentPage' had to be created for testing one of the methods which acted based on those values.

=== Testing Conditions ===
A total of 16 testing conditions were required to be performed for testing all the functions in menu items model file.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:

In this we had write unit test cases to test if the method returned a menu_item corresponding to a name.
Here we expect that if the method find_or_create_by_name() is passed the parameter "home", then it should return a value equal to "home"

2. #delete:

In this test cases were written to check if the method deletes current menu items and all child menu items.
In this case, if the parent menu item is deleted, all its child record should should be deleted.
For our specific case, the parent and its 3 child menu_items are expected to be deleted.

3. #above:

Test cases were written to check if the below conditions are satisfied:

3.1 "When current menu item has parent_id, the method returns the first parent menu item by querying the parent_id and current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test4, the method should return a value equal to the active record test3.

3.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test5, the method should return a value equal to the active record test1.

4. #below:

Test cases were written to check if the below conditions are satisfied:

4.1 "When current menu item has parent_id,the method returns the first parent menu item by querying the parent_id and current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test3, the method should return a value equal to the active record test4

4.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test1, the method should return a value equal to the active record test5.

5. .repack:

Test cases were written to check if the below conditions are satisfied:

5.1 "When current menu item has repack_id, the method finds all menus items with parent_id equal to repack_id and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value 1,
then, it will repack the sequence ids and returns the list of repacked seq_ids.
5.2 "When current menu item does not have repack_id, the method finds all menus items with parent_id null and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value Null,
it will match all the values with parent_id = Null and returns the list of repacked seq_ids.

6. .next_seq:

Test cases were written to check if the below conditions are satisfied:

6.1 "When parent_id is bigger than 0, the method selects corresponding menu items with inputted parent_id and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value 1, the method should return a value equal to 5.

6.2 "When parent_id is smaller than or equal to 0, the method selects corresponding menu items with parent_id null and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value nil, the method should return a value equal to 6.

7. .items_for_permissions:

Test cases were written to check if the below conditions are satisfied:

7.1 "When inputted variable (permission_ids) is nil and when the controller_action_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.2 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.3 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
the method should return an empty list.
7.4 "When inputted variable (permission_ids) is not nil and when the controller_action_id of current item is bigger than 0 and when perms exists,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records
which satisfy the condition.
7.5 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0, and when perms exists,
the method returns corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records which satisfy the condition.
7.6 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as a parameter,
the method should return an empty list.

The screenshot of the actual menu_item_spec.rb file is give below:
[[File:Menu item spec code.jpg]]

== Test Runs ==

A screenshot of the tests passing is shown here
[[File:RunTest.jpg]]

Screencast of a test run can be found here[https://www.youtube.com/watch?v=Acywhk_IjDY&feature=youtu.be]

== Conclusion and Learning Outcomes ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application.
In our case we did not have to install SimpleCov explicitly since it was already installed earlier.
After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder.
This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers, Models, Helpers in the app directory.

The learning outcomes after performing this project can be summarized in the following points:

1. We got an hands on experience about how to write tests following the Test Driven Development approach.

2. We learned about how to write units tests for models and controllers in RSpec.

3. We also learned how to understand the functionality of an already developed application.For our case, before writing the test cases for the menu_items.rb we had the understand how different models interacted with each other and how each action by different users would make changes in the database schema.

4. We also gained a better understanding about how different tables, columns of a large applications in structured in the database schema.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/sandeep993/expertiza/tree/menu_item_branch GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

File:RunTest.jpg

2018-04-03T00:15:18Z

Srajend:

CSC/ECE 517 Spring 2018/E1813 Test Menu Items Model

2018-04-03T00:13:47Z

Srajend:

This wiki page is for the description of changes made under E1813 OSS Assignment for Spring 2018, CSC/ECE 517.

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Test Driven-Development===
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,but more recently has created more general interest in its own right.
The TDD sequence can be can be summarized in following steps.

1.Add a Test:

TDD begins by writing succinct test cases to test each of the features. This is opposite to traditional software development paradigm where code is written first and then test cases are later written to test the application.

2.Run all tests and see if the new test fails:

This step validates that the test harness is working correctly, shows that the new test does not pass without requiring new code because the required behavior already exists, and it rules out the possibility that the new test is flawed and will always pass. The new test should fail for the expected reason. This step increases the developer's confidence in the new test.

3.Write the code:

The next step is to write the minimum amount of code that causes the test case to pass.

4.Run tests:

In this steps the test cases are run.If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

5. Refactor code:

In this step, refactoring of code is performed by following good design principles like removal of duplicate code, improving the readability and maintainability of the code.

6. Repeat:

Starting with another new test,the next step is to repeat the cycle to push the functionality forward.

Advantages of using TDD:
*Narrowing Problem Focus
*Tidier Code
*Not worrying about dependencies
*Easier refactoring
*Better Test coverage and fewer bugs

===Unit Testing===
[https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code are tested to catch errors early in the development process. For a model it involves testing the interface and on how it responds to commands and queries from outside. Model testing is bounded to the functionality of only the model under test and doesn't test how its collaborating models get affected based on this query.

Unit Testing provides several benefits which can be summarized in the below points.

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. It is to test all class and instance methods used in this file. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are :

1. Harish Pullagurla ( hpullag@ncsu.edu )

2. Kalyan Ghosh (kghosh@ncsu.edu)

3. Sandeep Rajendran(srajend@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
The steps that we followed to set up the Expertiza environment are as follows:

1. In the first step we installed the Virtual Box free software from Oracle in our local machines.

2. Then we downloaded the lightweight Lubuntu image file and imported the image file into the virtualbox ubuntu environment.

3. Then we executed the following set up commands in the terminal to set up the application in our local machine.

Setup commands:

*sudo su
*gem install bundler
*exit
*git clone [Your forked Expertiza repo url]
*cd expertiza
*bash setup.sh
(change config/database.yml, there is no MySQL password by default)
*bundle install
*rails server

After successfully setting up the environment, we could LogIn to the Expertiza application using our credentials.

To navigate to the menu_item.rb file we performed the following steps.

1. Open terminal inside the virtual environment.

2. Navigate to the model folder of the application by typing the following command in the terminal.

cd/expetiza/app/models

[[File:Menu_item.jpg]]

The menu_item_spec.rb test file is present in this directory

expertiza/spec/models/

The menu_item_spec.rb is the main file where test cases have been written.

To navigate to the menu_item.rb file we performed the following steps.

1. Open terminal inside the virtual environment.

2. Navigate to the model folder of the application by typing the following command in the terminal.

cd/expertiza/spec/models

[[File:Menu_item_spec.jpg]]

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Sample Views====

Sample view of menu bar item for instructor ans student are shown below.

[[File:E1813 memu bar instructor.png]]

View from a student account.
[[File:E1813menu bar expertiza.png]]

====Table ====
Table corresponding to menu item model has the following attributes:-

1. Name

2. Label :- These attributes talk about the labeling being given to the attributes

3. Parent id :- It tells about under which attribute does this particular attribute fall . If it is set has <null> it is the base category.

4. Sequence id :- It gives sequence numbering for determining the way the attributes are ordered within a parent.

5. controller action id

6. Content page id :- These attributes tell, to which direction/ page, this selection directs the user onto.

====Methods in the Model====

Different instance methods and class methods exist in this models . Brief description of each of them are : -

1. find_or_create_by_name(params) :- Class Method
This method finds or creates a new entry with the given name obtained in params

2. delete :- Instance Method
This methods deletes the entry and all the child entries ( entries having the same parent id ) lined to it

3. above :- Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below :- Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id) :- Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id) :- Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission :- Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "MenuItem.new()" method, giving different values for each of the test inputs to cover the required testing conditions.

before(:each) do
@test1 = MenuItem.new(name: "home1", parent_id: nil, seq: 1, controller_action_id: nil, content_page_id: nil, label: "newlabel")
@test1.save
end

The above is an example entry used for creating objects. 6 such test objects were created with entries giving combinations of parent_id and sequence numbers.

Before each test, all the objects are created, which is done using "before(:each)" key word.
Also several objects of 'ControllerAction' and 'ContentPage' had to be created for testing one of the methods which acted based on those values.

=== Testing Conditions ===
A total of 16 testing conditions were required to be performed for testing all the functions in menu items model file.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:

In this we had write unit test cases to test if the method returned a menu_item corresponding to a name.
Here we expect that if the method find_or_create_by_name() is passed the parameter "home", then it should return a value equal to "home"

2. #delete:

In this test cases were written to check if the method deletes current menu items and all child menu items.
In this case, if the parent menu item is deleted, all its child record should should be deleted.
For our specific case, the parent and its 3 child menu_items are expected to be deleted.

3. #above:

Test cases were written to check if the below conditions are satisfied:

3.1 "When current menu item has parent_id, the method returns the first parent menu item by querying the parent_id and current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test4, the method should return a value equal to the active record test3.

3.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test5, the method should return a value equal to the active record test1.

4. #below:

Test cases were written to check if the below conditions are satisfied:

4.1 "When current menu item has parent_id,the method returns the first parent menu item by querying the parent_id and current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test3, the method should return a value equal to the active record test4

4.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test1, the method should return a value equal to the active record test5.

5. .repack:

Test cases were written to check if the below conditions are satisfied:

5.1 "When current menu item has repack_id, the method finds all menus items with parent_id equal to repack_id and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value 1,
then, it will repack the sequence ids and returns the list of repacked seq_ids.
5.2 "When current menu item does not have repack_id, the method finds all menus items with parent_id null and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value Null,
it will match all the values with parent_id = Null and returns the list of repacked seq_ids.

6. .next_seq:

Test cases were written to check if the below conditions are satisfied:

6.1 "When parent_id is bigger than 0, the method selects corresponding menu items with inputted parent_id and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value 1, the method should return a value equal to 5.

6.2 "When parent_id is smaller than or equal to 0, the method selects corresponding menu items with parent_id null and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value nil, the method should return a value equal to 6.

7. .items_for_permissions:

Test cases were written to check if the below conditions are satisfied:

7.1 "When inputted variable (permission_ids) is nil and when the controller_action_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.2 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.3 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
the method should return an empty list.
7.4 "When inputted variable (permission_ids) is not nil and when the controller_action_id of current item is bigger than 0 and when perms exists,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records
which satisfy the condition.
7.5 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0, and when perms exists,
the method returns corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records which satisfy the condition.
7.6 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as a parameter,
the method should return an empty list.

The screenshot of the actual menu_item_spec.rb file is give below:
[[File:Menu item spec code.jpg]]

== Test Runs ==

A screenshot of the tests passing is shown here
[[File:RunTest.jpg]]

== Conclusion and Learning Outcomes ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application.
In our case we did not have to install SimpleCov explicitly since it was already installed earlier.
After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder.
This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers,Models,Helpers in the app directory.

The learning outcomes after performing this project can be summarized in the following points:

1. We got an hands on experience about how to write tests following the Test Driven Development approach.

2. We learned about how to write units tests for models and controllers in RSpec.

3. We also learned how to understand the functionality of an already developed application.For our case, before writing the test cases for the menu_items.rb we had the understand how different models interacted with each other and how each action by different users would make changes in the database schema.

4. We also gained a better understanding about how different tables, columns of a large applications in structured in the database schema.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/sandeep993/expertiza/tree/menu_item_branch GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

File:TestRun.png

2018-04-03T00:07:11Z

Srajend: uploaded a new version of "File:TestRun.png"

File:TestRun.png

2018-04-03T00:06:47Z

Srajend: uploaded a new version of "File:TestRun.png"

File:TestRun.png

2018-04-03T00:05:10Z

Srajend: