<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Zchen45</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Zchen45"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Zchen45"/>
	<updated>2026-05-26T01:01:36Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116895</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116895"/>
		<updated>2018-04-25T00:58:57Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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--&amp;quot;status&amp;quot; which is used to determine if this request will be approved or rejected.   &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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 &amp;quot;list&amp;quot; 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 &amp;quot;page&amp;quot;, otherwise, this method will redirect to &amp;quot;list&amp;quot; page. In summary, this method will direct to &amp;quot;show&amp;quot; page, when the user is able to be edited, otherwise, it will go to &amp;quot;list&amp;quot; page.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when method create is used to create a new user. &lt;br /&gt;
&lt;br /&gt;
[[File:Request3.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;get :keys&amp;quot; under the collection block of &amp;quot;resources :users&amp;quot; will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
1.1 &amp;quot;If the user is student, we check if proper redirection is taking place&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
1.2 &amp;quot;Else, the appropriate list of users should be rendered according to the role of the current user&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
2.1 &amp;quot;The page should render suggestions only of those user names that are similar to the one being typed and not all user names&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
4.1 &amp;quot;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&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
5.1 &amp;quot;check if it will render users/list_pending_requested page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
6.1 &amp;quot;check if the user is nil, will the page redirect to users/list page&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
6.2 &amp;quot;check if the user is not available for editing, will it redirect to users/list page&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
6.3 &amp;quot;check if the user is available for editing, will it render users/show page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
7.1 &amp;quot;check if the user id is nil or if the role is student and session id equals to id, will it redirect to home&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
7.2 &amp;quot;if the user is valid, check the return value&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
8.1 &amp;quot;check if this will render users/new page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Here isn't any conditional sentence. So only need to check whether the return value is expected.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
10.1 &amp;quot;Is the name new? If yes, good. Otherwise, register the user by email address.&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
10.2 &amp;quot;Is the user's information valid? If yes, good. Otherwise, fail&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
11.1 &amp;quot;does the user belong to any institution? If yes, good. Otherwise, set a new institution.&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
11.2 &amp;quot;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.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
12.1 &amp;quot;does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject.&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
12.2 &amp;quot;is the status Approved or Rejected?&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
12.2.1 &amp;quot;if the status is Approved, is the information valid? if yes, good. Otherwise fail&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
12.2.2 &amp;quot;if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request.&amp;quot;    &lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
13.1 &amp;quot;Here isn't any conditional sentence, so we just need to check if it renders users#edit page.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
14.1 &amp;quot;When user is updated successfully, it shows correct flash and redirects to users/show page.&amp;lt;br&amp;gt;&lt;br /&gt;
14.2 &amp;quot;When user is not updated successfully, it redirects to users/edit page.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
15.1 &amp;quot;When user is not deleted successfully, it shows an error and redirects to users/list page.&amp;quot; &lt;br /&gt;
     (This also covers the condition that user is deleted successfully.)&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
16.1 &amp;quot;When params[:id] is not nil, @private_key gets correct value.&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
16.2 &amp;quot;When params[:id] is nil, it redirects to /tree_display/drill page.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116894</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116894"/>
		<updated>2018-04-25T00:56:32Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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--&amp;quot;status&amp;quot; which is used to determine if this request will be approved or rejected.   &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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 &amp;quot;list&amp;quot; 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 &amp;quot;page&amp;quot;, otherwise, this method will redirect to &amp;quot;list&amp;quot; page. In summary, this method will direct to &amp;quot;show&amp;quot; page, when the user is able to be edited, otherwise, it will go to &amp;quot;list&amp;quot; page.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when method create is used to create a new user. &lt;br /&gt;
&lt;br /&gt;
[[File:Request2.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;get :keys&amp;quot; under the collection block of &amp;quot;resources :users&amp;quot; will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
1.1 &amp;quot;If the user is student, we check if proper redirection is taking place&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
1.2 &amp;quot;Else, the appropriate list of users should be rendered according to the role of the current user&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
2.1 &amp;quot;The page should render suggestions only of those user names that are similar to the one being typed and not all user names&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
4.1 &amp;quot;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&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
5.1 &amp;quot;check if it will render users/list_pending_requested page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
6.1 &amp;quot;check if the user is nil, will the page redirect to users/list page&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
6.2 &amp;quot;check if the user is not available for editing, will it redirect to users/list page&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
6.3 &amp;quot;check if the user is available for editing, will it render users/show page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
7.1 &amp;quot;check if the user id is nil or if the role is student and session id equals to id, will it redirect to home&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
7.2 &amp;quot;if the user is valid, check the return value&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
8.1 &amp;quot;check if this will render users/new page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Here isn't any conditional sentence. So only need to check whether the return value is expected.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
10.1 &amp;quot;Is the name new? If yes, good. Otherwise, register the user by email address.&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
10.2 &amp;quot;Is the user's information valid? If yes, good. Otherwise, fail&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
11.1 &amp;quot;does the user belong to any institution? If yes, good. Otherwise, set a new institution.&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
11.2 &amp;quot;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.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
12.1 &amp;quot;does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject.&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
12.2 &amp;quot;is the status Approved or Rejected?&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
12.2.1 &amp;quot;if the status is Approved, is the information valid? if yes, good. Otherwise fail&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
12.2.2 &amp;quot;if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request.&amp;quot;    &lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
13.1 &amp;quot;Here isn't any conditional sentence, so we just need to check if it renders users#edit page.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
14.1 &amp;quot;When user is updated successfully, it shows correct flash and redirects to users/show page.&amp;lt;br&amp;gt;&lt;br /&gt;
14.2 &amp;quot;When user is not updated successfully, it redirects to users/edit page.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
15.1 &amp;quot;When user is not deleted successfully, it shows an error and redirects to users/list page.&amp;quot; &lt;br /&gt;
     (This also covers the condition that user is deleted successfully.)&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
16.1 &amp;quot;When params[:id] is not nil, @private_key gets correct value.&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
16.2 &amp;quot;When params[:id] is nil, it redirects to /tree_display/drill page.&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116890</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116890"/>
		<updated>2018-04-25T00:52:33Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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--&amp;quot;status&amp;quot; which is used to determine if this request will be approved or rejected.   &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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 &amp;quot;list&amp;quot; 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 &amp;quot;page&amp;quot;, otherwise, this method will redirect to &amp;quot;list&amp;quot; page. In summary, this method will direct to &amp;quot;show&amp;quot; page, when the user is able to be edited, otherwise, it will go to &amp;quot;list&amp;quot; page.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when method create is used to create a new user. &lt;br /&gt;
&lt;br /&gt;
[[File:Request3.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;get :keys&amp;quot; under the collection block of &amp;quot;resources :users&amp;quot; will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
1.1 &amp;quot;If the user is student, we check if proper redirection is taking place&amp;quot;&amp;lt;br&amp;gt; &lt;br /&gt;
1.2 &amp;quot;Else, the appropriate list of users should be rendered according to the role of the current user&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
2.1 &amp;quot;The page should render suggestions only of those user names that are similar to the one being typed and not all user names&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
4.1 &amp;quot;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&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
5.1 &amp;quot;check if it will render users/list_pending_requested page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
6.1 &amp;quot;check if the user is nil, will the page redirect to users/list page&amp;quot;&lt;br /&gt;
6.2 &amp;quot;check if the user is not available for editing, will it redirect to users/list page&amp;quot;&lt;br /&gt;
6.3 &amp;quot;check if the user is available for editing, will it render users/show page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
7.1 &amp;quot;check if the user id is nil or if the role is student and session id equals to id, will it redirect to home&amp;quot;&lt;br /&gt;
7.2 &amp;quot;if the user is valid, check the return value&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
8.1 &amp;quot;check if this will render users/new page&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Here isn't any conditional sentence. So only need to check whether the return value is expected.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
10.1 &amp;quot;Is the name new? If yes, good. Otherwise, register the user by email address.&amp;quot;&lt;br /&gt;
10.2 &amp;quot;Is the user's information valid? If yes, good. Otherwise, fail&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
11.1 &amp;quot;does the user belong to any institution? If yes, good. Otherwise, set a new institution.&amp;quot;&lt;br /&gt;
11.2 &amp;quot;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.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
12.1 &amp;quot;does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject.&amp;quot;&lt;br /&gt;
12.2 &amp;quot;is the status Approved or Rejected?&amp;quot;&lt;br /&gt;
12.2.1 &amp;quot;if the status is Approved, is the information valid? if yes, good. Otherwise fail&amp;quot;&lt;br /&gt;
12.2.2 &amp;quot;if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request.&amp;quot;    &lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
13.1 &amp;quot;Here isn't any conditional sentence, so we just need to check if it renders users#edit page.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
14.1 &amp;quot;When user is updated successfully, it shows correct flash and redirects to users/show page.&amp;quot;&lt;br /&gt;
14.2 &amp;quot;When user is not updated successfully, it redirects to users/edit page.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
15.1 &amp;quot;When user is not deleted successfully, it shows an error and redirects to users/list page.&amp;quot; &lt;br /&gt;
     (This also covers the condition that user is deleted successfully.)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
16.1 &amp;quot;When params[:id] is not nil, @private_key gets correct value.&amp;quot;&lt;br /&gt;
16.2 &amp;quot;When params[:id] is nil, it redirects to /tree_display/drill page.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Request3.png&amp;diff=116889</id>
		<title>File:Request3.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Request3.png&amp;diff=116889"/>
		<updated>2018-04-25T00:52:15Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: request3&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;request3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116883</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116883"/>
		<updated>2018-04-25T00:50:57Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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--&amp;quot;status&amp;quot; which is used to determine if this request will be approved or rejected.   &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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 &amp;quot;list&amp;quot; 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 &amp;quot;page&amp;quot;, otherwise, this method will redirect to &amp;quot;list&amp;quot; page. In summary, this method will direct to &amp;quot;show&amp;quot; page, when the user is able to be edited, otherwise, it will go to &amp;quot;list&amp;quot; page.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when method create is used to create a new user. &lt;br /&gt;
&lt;br /&gt;
[[File:Request2.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;resources :users&amp;quot; in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;get :keys&amp;quot; under the collection block of &amp;quot;resources :users&amp;quot; will enable Rails to recognize paths such as /users/keys with GET, and route to the key action of UsersController.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
1.1 &amp;quot;If the user is student, we check if proper redirection is taking place&amp;quot;&lt;br /&gt;
1.2 &amp;quot;Else, the appropriate list of users should be rendered according to the role of the current user&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
2.1 &amp;quot;The page should render suggestions only of those user names that are similar to the one being typed and not all user names&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
4.1 &amp;quot;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&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
5.1 &amp;quot;check if it will render users/list_pending_requested page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&lt;br /&gt;
6.1 &amp;quot;check if the user is nil, will the page redirect to users/list page&amp;quot;&lt;br /&gt;
6.2 &amp;quot;check if the user is not available for editing, will it redirect to users/list page&amp;quot;&lt;br /&gt;
6.3 &amp;quot;check if the user is available for editing, will it render users/show page&amp;quot;&lt;br /&gt;
&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
7.1 &amp;quot;check if the user id is nil or if the role is student and session id equals to id, will it redirect to home&amp;quot;&lt;br /&gt;
7.2 &amp;quot;if the user is valid, check the return value&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
8.1 &amp;quot;check if this will render users/new page&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Here isn't any conditional sentence. So only need to check whether the return value is expected.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
10.1 &amp;quot;Is the name new? If yes, good. Otherwise, register the user by email address.&amp;quot;&lt;br /&gt;
10.2 &amp;quot;Is the user's information valid? If yes, good. Otherwise, fail&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
11.1 &amp;quot;does the user belong to any institution? If yes, good. Otherwise, set a new institution.&amp;quot;&lt;br /&gt;
11.2 &amp;quot;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.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
12.1 &amp;quot;does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject.&amp;quot;&lt;br /&gt;
12.2 &amp;quot;is the status Approved or Rejected?&amp;quot;&lt;br /&gt;
12.2.1 &amp;quot;if the status is Approved, is the information valid? if yes, good. Otherwise fail&amp;quot;&lt;br /&gt;
12.2.2 &amp;quot;if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request.&amp;quot;    &lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
13.1 &amp;quot;Here isn't any conditional sentence, so we just need to check if it renders users#edit page.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
14.1 &amp;quot;When user is updated successfully, it shows correct flash and redirects to users/show page.&amp;quot;&lt;br /&gt;
14.2 &amp;quot;When user is not updated successfully, it redirects to users/edit page.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
15.1 &amp;quot;When user is not deleted successfully, it shows an error and redirects to users/list page.&amp;quot; &lt;br /&gt;
     (This also covers the condition that user is deleted successfully.)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
16.1 &amp;quot;When params[:id] is not nil, @private_key gets correct value.&amp;quot;&lt;br /&gt;
16.2 &amp;quot;When params[:id] is nil, it redirects to /tree_display/drill page.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Request2.png&amp;diff=116882</id>
		<title>File:Request2.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Request2.png&amp;diff=116882"/>
		<updated>2018-04-25T00:50:38Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: request2&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;request2&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116220</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116220"/>
		<updated>2018-04-06T23:02:13Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Test Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request_frame.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Here isn't any conditional sentence. So only need to check whether the return value is expected.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
10.1 &amp;quot;Is the name new? If yes, good. Otherwise, register the user by email address.&amp;quot;&lt;br /&gt;
10.2 &amp;quot;Is the user's information valid? If yes, good. Otherwise, fail&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
11.1 &amp;quot;does the user belong to any institution? If yes, good. Otherwise, set a new institution.&amp;quot;&lt;br /&gt;
11.2 &amp;quot;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.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
12.1 &amp;quot;does the request have one status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject.&amp;quot;&lt;br /&gt;
12.2 &amp;quot;is the status Approved or Rejected?&amp;quot;&lt;br /&gt;
12.2.1 &amp;quot;if the status is Approved, is the information valid? if yes, good. Otherwise fail&amp;quot;&lt;br /&gt;
12.2.2 &amp;quot;if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request.&amp;quot;    &lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116219</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116219"/>
		<updated>2018-04-06T22:58:03Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Test Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request_frame.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Here isn't any conditional sentence. So only need to check whether the return value is expected.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
10.1 &amp;quot;Is the name new? If yes, good. Otherwise, register the user by email address.&amp;quot;&lt;br /&gt;
10.2 &amp;quot;Is the user's information valid? If yes, good. Otherwise, fail&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
11.1 &amp;quot;does the user have an institution? If yes, good. Otherwise, set a new institution.&amp;quot;&lt;br /&gt;
11.2 &amp;quot;is the user already existed and valid? If both yes, good. If the user already existed, send notification. If the information is not valid, fail.&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
12.1 &amp;quot;does the request have a status? if yes and the parameters of the request are completed, good. Otherwise, submit a status, approve or reject.&amp;quot;&lt;br /&gt;
12.2 &amp;quot;is the status Approved or Rejected?&amp;quot;&lt;br /&gt;
12.2.1 &amp;quot;if the status is Approved, is the information valid? if yes, good. Otherwise fail&amp;quot;&lt;br /&gt;
12.2.2 &amp;quot;if the status is Rejected, is the processing correctly? if yes, reject successfully. Otherwise, error processing request.&amp;quot;    &lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116218</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116218"/>
		<updated>2018-04-06T22:42:03Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Test Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request_frame.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Valid requests&amp;quot;&lt;br /&gt;
    At here I will test if the &lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
10.1 &amp;quot;2 conditions: Is the name new? If yes, good. Otherwise, register the user by email address.&amp;quot;&lt;br /&gt;
10.2 &amp;quot;2 conditions: Is the user's information valid? If yes, good. Otherwise, fail&amp;quot;&lt;br /&gt;
     So there are 4 testing conditions in total.&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
11.1 &amp;quot;2 conditions: does the user have an institution? If yes, good. Otherwise, set a new institution.&amp;quot;&lt;br /&gt;
11.2 &amp;quot;3 conditions: is the user already existed and valid? If yes, good. If the user already existed or the information is not valid, fail.&amp;quot;&lt;br /&gt;
     So there are 6 testing conditions in total.&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116217</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116217"/>
		<updated>2018-04-06T22:31:38Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Test Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request_frame.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Valid requests&amp;quot;&lt;br /&gt;
    At here I will test if the &lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
10.1 &amp;quot;2 conditions: is the name new? if yes, good. Otherwise, register the user by email address.&amp;quot;&lt;br /&gt;
10.2 &amp;quot;2 conditions: is the user's information valid?&amp;quot;&lt;br /&gt;
So there are 4 testing conditions in total.&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
11.1&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116216</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116216"/>
		<updated>2018-04-06T22:20:01Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Test Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request_frame.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
9.1 &amp;quot;Valid requests&amp;quot;&lt;br /&gt;
    At here I will test if the &lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Request_frame.png&amp;diff=116215</id>
		<title>File:Request frame.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Request_frame.png&amp;diff=116215"/>
		<updated>2018-04-06T22:05:32Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: uploaded a new version of &amp;amp;quot;File:Request frame.png&amp;amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;introduction of request frame&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116214</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116214"/>
		<updated>2018-04-06T22:03:33Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request_frame.png]]&lt;br /&gt;
&lt;br /&gt;
(This image will be helpful for the next 4 methods)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116213</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116213"/>
		<updated>2018-04-06T22:02:41Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request_frame.png]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116212</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116212"/>
		<updated>2018-04-06T22:02:22Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request_frame.jpg]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116211</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116211"/>
		<updated>2018-04-06T22:02:05Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Request frame.jpg]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116210</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116210"/>
		<updated>2018-04-06T22:01:09Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create accounts.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Request_frame.png&amp;diff=116209</id>
		<title>File:Request frame.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Request_frame.png&amp;diff=116209"/>
		<updated>2018-04-06T22:00:33Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: introduction of request frame&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;introduction of request frame&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116206</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116206"/>
		<updated>2018-04-06T21:28:07Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create a student account.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the guest sends a request for the account to Expertiza administrator.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the Expertiza administrator deals with the guests' requests.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116199</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116199"/>
		<updated>2018-04-06T21:04:14Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when the user wants to create a student account.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116197</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116197"/>
		<updated>2018-04-06T20:56:57Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116196</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116196"/>
		<updated>2018-04-06T20:56:23Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This method is called when a TA or instructor request 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116194</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116194"/>
		<updated>2018-04-06T20:42:38Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116193</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116193"/>
		<updated>2018-04-06T20:34:06Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. request_new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. create&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. create_requested_user_record&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. create_approved_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116192</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116192"/>
		<updated>2018-04-06T20:32:39Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116191</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116191"/>
		<updated>2018-04-06T20:30:57Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes: (For the unexplained attributes, some of them are easy to understand and explaining others makes no sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116190</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116190"/>
		<updated>2018-04-06T20:30:16Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes:(For the unexplained attributes, some of them are easy to understand and explaining others makes no sense here)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. master_permission_granted&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. handle&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. digital_certificate&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;17. persistence_token&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;18. timezonepref&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;19. public_key&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;20. copy_of_emails&amp;lt;/b&amp;gt; - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;21. institution_id&amp;lt;/b&amp;gt; - Reference to an entry in institutions table, referring to the institution at which this user is registered&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116188</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116188"/>
		<updated>2018-04-06T20:04:16Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, parent_id is the table id of the administrator who created the acceptance for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt; - 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;10. email_on_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else is reviewing my work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;11. email_on_submission&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else submits work I am assigned to review.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;12. email_on_review_of_review&amp;lt;/b&amp;gt; - It is a boolean value used to check whether someone else reviews one of my reviews.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. is_new_user&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116187</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116187"/>
		<updated>2018-04-06T19:35:46Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; - It is used to distinguish the users as super-administrator, administrator, instructor or student.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. fullname&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. email&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. parent_id&amp;lt;/b&amp;gt; - For an instructor, parent_id is the table id of the administrator who created the acceptance for the instructor; otherwise, empty.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. private_by_default&amp;lt;/b&amp;gt; - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;9. mru_directory_path&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116184</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116184"/>
		<updated>2018-04-06T19:14:30Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt; - It is the password after encrypting.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. password_salt&amp;lt;/b&amp;gt; - It stores the information of the encryption for the password verification.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. role_id&amp;lt;/b&amp;gt; -&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116183</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116183"/>
		<updated>2018-04-06T18:57:54Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. crypted_password&amp;lt;/b&amp;gt;: s&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116182</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116182"/>
		<updated>2018-04-06T18:56:59Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;1. Name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2.&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116181</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116181"/>
		<updated>2018-04-06T18:56:42Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Table */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
Newly-created file:&lt;br /&gt;
&lt;br /&gt;
  spec/users_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
Tested file:&lt;br /&gt;
&lt;br /&gt;
  app/controllers/users_controller.rb&lt;br /&gt;
&lt;br /&gt;
Related view files:&lt;br /&gt;
&lt;br /&gt;
  app/views/users/edit.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/keys.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/list_pending_requested.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/request_new.html.erb&lt;br /&gt;
&lt;br /&gt;
  app/views/users/show.html.erb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
&lt;br /&gt;
1. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
2. Xiao Ma(xma21@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Zekun Zhang(zzhang56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
4. Zhiyu Chen(zchen45@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
&lt;br /&gt;
Table corresponding to User model has the following attributes:&lt;br /&gt;
&lt;br /&gt;
1. Name&lt;br /&gt;
&lt;br /&gt;
2.&lt;br /&gt;
&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&amp;lt;b&amp;gt;1. index&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;2. auto_complete_for_user_name&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;3. set_anonymized_view&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;4. list&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;5. list_pending_requested&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;6. show_selection&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;7. show&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;8. new&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;13. edit&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;14. update&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;15. destroy&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;16. keys&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
1. Download and set the Expertiza environment&lt;br /&gt;
2. Determine which methods should be tested&lt;br /&gt;
3. Define all the conditions needed to be tested for each method&lt;br /&gt;
&lt;br /&gt;
The methods have already been introduced on above, here are the test plan for each method: &lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116063</id>
		<title>CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018/E1823_Write_integration_tests_for_users_controller.rb&amp;diff=116063"/>
		<updated>2018-04-05T23:53:48Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.&lt;br /&gt;
== Project Statement ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
The files to be understood and created are:&lt;br /&gt;
&lt;br /&gt;
1. app/models/menu_items.rb&lt;br /&gt;
&lt;br /&gt;
2. spec/models/menu_items_spec.rb&lt;br /&gt;
&lt;br /&gt;
=== Team Members ===&lt;br /&gt;
Students who collaborated to work on this problem statement are :&lt;br /&gt;
&lt;br /&gt;
1. Harish Pullagurla ( hpullag@ncsu.edu )&lt;br /&gt;
&lt;br /&gt;
2. Kalyan Ghosh (kghosh@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
3. Sandeep Rajendran(srajend@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
== Functionality of the Controller ==&lt;br /&gt;
=== Table ===&lt;br /&gt;
=== Methods ===&lt;br /&gt;
&lt;br /&gt;
== Testing Conditions ==&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115107</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115107"/>
		<updated>2018-03-26T07:41:45Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Scores */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_similarity_score(cycle)&lt;br /&gt;
	similarity_score = 0.0&lt;br /&gt;
	count = 0.0&lt;br /&gt;
	for pivot in 0...cycle.size - 1 do&lt;br /&gt;
		pivot_score = cycle[pivot][1]&lt;br /&gt;
		for other in pivot + 1...cycle.size do&lt;br /&gt;
			similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
			count += 1.0&lt;br /&gt;
      		end&lt;br /&gt;
    	end&lt;br /&gt;
    	similarity_score /= count unless count == 0.0&lt;br /&gt;
    	similarity_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_deviation_score(cycle)&lt;br /&gt;
  	deviation_score = 0.0&lt;br /&gt;
  	count = 0.0&lt;br /&gt;
  	for member in 0...cycle.size do&lt;br /&gt;
    		participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
    		total_score = participant.review_score&lt;br /&gt;
    		deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
    		count += 1.0&lt;br /&gt;
  	end&lt;br /&gt;
  	deviation_score /= count unless count == 0.0&lt;br /&gt;
  	deviation_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_similarity_score(cycle) function in CollusionCycle class. The function is very simple, as it doesn't call any other functions. We only need to input the appropriate data and check whether the output is correct. So for each cases, 2 nodes or 3 nodes, I set different cycle as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_similarity_score&amp;quot; do&lt;br /&gt;
    	it &amp;quot;similarity score of 2 node test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;similarity score of 3 node test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 95], [participant3, 85]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
	it &amp;quot;similarity score of 4 node test&amp;quot; do&lt;br /&gt;
		cycle = [[participant1, 100], [participant2, 95], [participant3, 95], [participant4, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (5)&lt;br /&gt;
	end&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_deviation_score(cycle) function in CollusionCycle class, It calls review_score method from AssignmentParticipant class. This method will return a standard score of the participant. But in our project, how the review_score method works and whether the result of the review_score method is correct are not parts of our duty (PS: I think it should be tested in unit tests of AssignmentParticipant class). So I set the results of review_score method for each participant. And also set different cycles as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_deviation_score&amp;quot; do&lt;br /&gt;
	before(:each) do&lt;br /&gt;
		allow(participant1).to receive(:id).and_return(1)&lt;br /&gt;
		allow(participant2).to receive(:id).and_return(2)&lt;br /&gt;
		allow(participant3).to receive(:id).and_return(3)&lt;br /&gt;
		allow(participant4).to receive(:id).and_return(4)     &lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(1).and_return(participant1)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(2).and_return(participant2)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(3).and_return(participant3)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(4).and_return(participant4)&lt;br /&gt;
		allow(participant1).to receive(:review_score).and_return(90) 			&lt;br /&gt;
		allow(participant2).to receive(:review_score).and_return(80)&lt;br /&gt;
		allow(participant3).to receive(:review_score).and_return(91)&lt;br /&gt;
		allow(participant4).to receive(:review_score).and_return(95)&lt;br /&gt;
	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 2 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (7.5)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 3 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90], [participant3, 91]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 4 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90], [participant3, 91], [participant4, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
    	end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115106</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115106"/>
		<updated>2018-03-26T07:38:39Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_similarity_score(cycle)&lt;br /&gt;
	similarity_score = 0.0&lt;br /&gt;
	count = 0.0&lt;br /&gt;
	for pivot in 0...cycle.size - 1 do&lt;br /&gt;
		pivot_score = cycle[pivot][1]&lt;br /&gt;
		for other in pivot + 1...cycle.size do&lt;br /&gt;
			similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
			count += 1.0&lt;br /&gt;
      		end&lt;br /&gt;
    	end&lt;br /&gt;
    	similarity_score /= count unless count == 0.0&lt;br /&gt;
    	similarity_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_deviation_score(cycle)&lt;br /&gt;
  	deviation_score = 0.0&lt;br /&gt;
  	count = 0.0&lt;br /&gt;
  	for member in 0...cycle.size do&lt;br /&gt;
    		participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
    		total_score = participant.review_score&lt;br /&gt;
    		deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
    		count += 1.0&lt;br /&gt;
  	end&lt;br /&gt;
  	deviation_score /= count unless count == 0.0&lt;br /&gt;
  	deviation_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_similarity_score(cycle) function in CollusionCycle class. The function is very simple, as it doesn't call any other functions. We only need to input the appropriate data and check whether the output is correct. So for each cases, 2 nodes or 3 nodes, I set different cycle as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_similarity_score&amp;quot; do&lt;br /&gt;
    	it &amp;quot;similarity score of 2 node test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;similarity score of 3 node test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 95], [participant3, 85]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
	it &amp;quot;similarity score of 4 node test&amp;quot; do&lt;br /&gt;
		cycle = [[participant1, 100], [participant2, 95], [participant3, 95], [participant4, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (5)&lt;br /&gt;
	end&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_deviation_score(cycle) function in CollusionCycle class, It calls review_score method from AssignmentParticipant class. This method will return a standard score of the participant. But in our project, how the review_score method works and whether the result of the review_score method is correct are not parts of our duty (PS: I think it should be tested in unit tests of AssignmentParticipant class). So I set the results of review_score method for each participant. And also set different cycles as input and check the results of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_deviation_score&amp;quot; do&lt;br /&gt;
	before(:each) do&lt;br /&gt;
		allow(participant1).to receive(:id).and_return(1)&lt;br /&gt;
		allow(participant2).to receive(:id).and_return(2)&lt;br /&gt;
		allow(participant3).to receive(:id).and_return(3)&lt;br /&gt;
		allow(participant4).to receive(:id).and_return(4)     &lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(1).and_return(participant1)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(2).and_return(participant2)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(3).and_return(participant3)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(4).and_return(participant4)&lt;br /&gt;
		allow(participant1).to receive(:review_score).and_return(90) 			&lt;br /&gt;
		allow(participant2).to receive(:review_score).and_return(80)&lt;br /&gt;
		allow(participant3).to receive(:review_score).and_return(91)&lt;br /&gt;
		allow(participant4).to receive(:review_score).and_return(95)&lt;br /&gt;
	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 2 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (7.5)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 3 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90], [participant3, 91]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 4 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90], [participant3, 91], [participant4, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
    	end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115105</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115105"/>
		<updated>2018-03-26T07:37:49Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_similarity_score(cycle)&lt;br /&gt;
	similarity_score = 0.0&lt;br /&gt;
	count = 0.0&lt;br /&gt;
	for pivot in 0...cycle.size - 1 do&lt;br /&gt;
		pivot_score = cycle[pivot][1]&lt;br /&gt;
		for other in pivot + 1...cycle.size do&lt;br /&gt;
			similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
			count += 1.0&lt;br /&gt;
      		end&lt;br /&gt;
    	end&lt;br /&gt;
    	similarity_score /= count unless count == 0.0&lt;br /&gt;
    	similarity_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_deviation_score(cycle)&lt;br /&gt;
  deviation_score = 0.0&lt;br /&gt;
  count = 0.0&lt;br /&gt;
  for member in 0...cycle.size do&lt;br /&gt;
    participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
    total_score = participant.review_score&lt;br /&gt;
    deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
    count += 1.0&lt;br /&gt;
  end&lt;br /&gt;
  deviation_score /= count unless count == 0.0&lt;br /&gt;
  deviation_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_similarity_score(cycle) function in CollusionCycle class. The function is very simple, as it doesn't call any other functions. We only need to input the appropriate data and check whether the output is correct. So for each cases, 2 nodes or 3 nodes, I set different cycle as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_similarity_score&amp;quot; do&lt;br /&gt;
    	it &amp;quot;similarity score of 2 node test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;similarity score of 3 node test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 95], [participant3, 85]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
	it &amp;quot;similarity score of 4 node test&amp;quot; do&lt;br /&gt;
		cycle = [[participant1, 100], [participant2, 95], [participant3, 95], [participant4, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (5)&lt;br /&gt;
	end&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_deviation_score(cycle) function in CollusionCycle class, It calls review_score method from AssignmentParticipant class. This method will return a standard score of the participant. But in our project, how the review_score method works and whether the result of the review_score method is correct are not parts of our duty (PS: I think it should be tested in unit tests of AssignmentParticipant class). So I set the results of review_score method for each participant. And also set different cycles as input and check the results of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_deviation_score&amp;quot; do&lt;br /&gt;
	before(:each) do&lt;br /&gt;
		allow(participant1).to receive(:id).and_return(1)&lt;br /&gt;
		allow(participant2).to receive(:id).and_return(2)&lt;br /&gt;
		allow(participant3).to receive(:id).and_return(3)&lt;br /&gt;
		allow(participant4).to receive(:id).and_return(4)     &lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(1).and_return(participant1)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(2).and_return(participant2)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(3).and_return(participant3)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(4).and_return(participant4)&lt;br /&gt;
		allow(participant1).to receive(:review_score).and_return(90) 			&lt;br /&gt;
		allow(participant2).to receive(:review_score).and_return(80)&lt;br /&gt;
		allow(participant3).to receive(:review_score).and_return(91)&lt;br /&gt;
		allow(participant4).to receive(:review_score).and_return(95)&lt;br /&gt;
	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 2 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (7.5)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 3 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90], [participant3, 91]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 4 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90], [participant3, 91], [participant4, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
    	end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115104</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115104"/>
		<updated>2018-03-26T07:36:12Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Scores */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_similarity_score(cycle)&lt;br /&gt;
  similarity_score = 0.0&lt;br /&gt;
  count = 0.0&lt;br /&gt;
  for pivot in 0...cycle.size - 1 do&lt;br /&gt;
    pivot_score = cycle[pivot][1]&lt;br /&gt;
    for other in pivot + 1...cycle.size do&lt;br /&gt;
      similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
  similarity_score /= count unless count == 0.0&lt;br /&gt;
  similarity_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_deviation_score(cycle)&lt;br /&gt;
  deviation_score = 0.0&lt;br /&gt;
  count = 0.0&lt;br /&gt;
  for member in 0...cycle.size do&lt;br /&gt;
    participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
    total_score = participant.review_score&lt;br /&gt;
    deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
    count += 1.0&lt;br /&gt;
  end&lt;br /&gt;
  deviation_score /= count unless count == 0.0&lt;br /&gt;
  deviation_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_similarity_score(cycle) function in CollusionCycle class. The function is very simple, as it doesn't call any other functions. We only need to input the appropriate data and check whether the output is correct. So for each cases, 2 nodes or 3 nodes, I set different cycle as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_similarity_score&amp;quot; do&lt;br /&gt;
    	it &amp;quot;similarity score of 2 node test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;similarity score of 3 node test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 95], [participant3, 85]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
	it &amp;quot;similarity score of 4 node test&amp;quot; do&lt;br /&gt;
		cycle = [[participant1, 100], [participant2, 95], [participant3, 95], [participant4, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (5)&lt;br /&gt;
	end&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_deviation_score(cycle) function in CollusionCycle class, It calls review_score method from AssignmentParticipant class. This method will return a standard score of the participant. But in our project, how the review_score method works and whether the result of the review_score method is correct are not parts of our duty (PS: I think it should be tested in unit tests of AssignmentParticipant class). So I set the results of review_score method for each participant. And also set different cycles as input and check the results of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_deviation_score&amp;quot; do&lt;br /&gt;
	before(:each) do&lt;br /&gt;
		allow(participant1).to receive(:id).and_return(1)&lt;br /&gt;
		allow(participant2).to receive(:id).and_return(2)&lt;br /&gt;
		allow(participant3).to receive(:id).and_return(3)&lt;br /&gt;
		allow(participant4).to receive(:id).and_return(4)     &lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(1).and_return(participant1)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(2).and_return(participant2)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(3).and_return(participant3)&lt;br /&gt;
		allow(AssignmentParticipant).to receive(:find).with(4).and_return(participant4)&lt;br /&gt;
		allow(participant1).to receive(:review_score).and_return(90) 			&lt;br /&gt;
		allow(participant2).to receive(:review_score).and_return(80)&lt;br /&gt;
		allow(participant3).to receive(:review_score).and_return(91)&lt;br /&gt;
		allow(participant4).to receive(:review_score).and_return(95)&lt;br /&gt;
	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 2 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (7.5)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 3 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90], [participant3, 91]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;deviation score for 4 nodes test&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 95], [participant2, 90], [participant3, 91], [participant4, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
    	end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115103</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115103"/>
		<updated>2018-03-26T07:13:37Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Scores */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_similarity_score(cycle)&lt;br /&gt;
  similarity_score = 0.0&lt;br /&gt;
  count = 0.0&lt;br /&gt;
  for pivot in 0...cycle.size - 1 do&lt;br /&gt;
    pivot_score = cycle[pivot][1]&lt;br /&gt;
    for other in pivot + 1...cycle.size do&lt;br /&gt;
      similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
  similarity_score /= count unless count == 0.0&lt;br /&gt;
  similarity_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_deviation_score(cycle)&lt;br /&gt;
  deviation_score = 0.0&lt;br /&gt;
  count = 0.0&lt;br /&gt;
  for member in 0...cycle.size do&lt;br /&gt;
    participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
    total_score = participant.review_score&lt;br /&gt;
    deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
    count += 1.0&lt;br /&gt;
  end&lt;br /&gt;
  deviation_score /= count unless count == 0.0&lt;br /&gt;
  deviation_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_similarity_score(cycle) function in CollusionCycle class. The function is very simple, as it doesn't call any other functions. We only need to input the appropriate data and check whether the output is correct. So for each cases, 2 nodes or 3 nodes, I set different cycle as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_similarity_score&amp;quot; do&lt;br /&gt;
  it &amp;quot;similarity score of 2 node&amp;quot; do&lt;br /&gt;
    cycle = [[participant1, 100], [participant2, 90]]&lt;br /&gt;
    expect(colcyc.cycle_similarity_score(cycle)).to eq (10.0)&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  it &amp;quot;similarity score of 3 node&amp;quot; do&lt;br /&gt;
    cycle = [[participant1, 100], [participant2, 95], [participant3, 85]]&lt;br /&gt;
    expect(colcyc.cycle_similarity_score(cycle)).to eq (10)&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below is the unit test for the cycle_deviation_score(cycle) function in CollusionCycle class, It calls review_score method from AssignmentParticipant class. This method will return a standard score of the participant. But in our project, how the review_score method works and whether the result of the review_score method is correct are not parts of our duty (PS: I think it should be tested in unit tests of AssignmentParticipant class). So I set the results of review_score method for each participant. And also set different cycles as input and check the results of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_deviation_score&amp;quot; do&lt;br /&gt;
  it &amp;quot;1&amp;quot; do&lt;br /&gt;
    cycle = [[participant1, 95], [participant2, 90]]&lt;br /&gt;
    allow(participant1).to receive(:id).and_return(1)&lt;br /&gt;
    allow(participant2).to receive(:id).and_return(2)     &lt;br /&gt;
    allow(AssignmentParticipant).to receive(:find).with(1).and_return(participant1)&lt;br /&gt;
    allow(AssignmentParticipant).to receive(:find).with(2).and_return(participant2)&lt;br /&gt;
    allow(participant1).to receive(:review_score).and_return(90) 			&lt;br /&gt;
    allow(participant2).to receive(:review_score).and_return(80)&lt;br /&gt;
    expect(colcyc.cycle_deviation_score(cycle)).to eq (7.5)&lt;br /&gt;
  end&lt;br /&gt;
&lt;br /&gt;
  it &amp;quot;2&amp;quot; do&lt;br /&gt;
    cycle = [[participant1, 95], [participant2, 90], [participant3, 91]]&lt;br /&gt;
    allow(participant1).to receive(:id).and_return(1)&lt;br /&gt;
    allow(participant2).to receive(:id).and_return(2)&lt;br /&gt;
    allow(participant3).to receive(:id).and_return(3)     &lt;br /&gt;
    allow(AssignmentParticipant).to receive(:find).with(1).and_return(participant1)&lt;br /&gt;
    allow(AssignmentParticipant).to receive(:find).with(2).and_return(participant2)&lt;br /&gt;
    allow(AssignmentParticipant).to receive(:find).with(3).and_return(participant3)&lt;br /&gt;
    allow(participant1).to receive(:review_score).and_return(90) 			&lt;br /&gt;
    allow(participant2).to receive(:review_score).and_return(80)&lt;br /&gt;
    allow(participant3).to receive(:review_score).and_return(91)&lt;br /&gt;
    expect(colcyc.cycle_deviation_score(cycle)).to eq (5.0)&lt;br /&gt;
  end&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115102</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115102"/>
		<updated>2018-03-26T06:58:53Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_similarity_score(cycle)&lt;br /&gt;
  similarity_score = 0.0&lt;br /&gt;
  count = 0.0&lt;br /&gt;
  for pivot in 0...cycle.size - 1 do&lt;br /&gt;
    pivot_score = cycle[pivot][1]&lt;br /&gt;
    for other in pivot + 1...cycle.size do&lt;br /&gt;
      similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
  similarity_score /= count unless count == 0.0&lt;br /&gt;
  similarity_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_deviation_score(cycle)&lt;br /&gt;
  deviation_score = 0.0&lt;br /&gt;
  count = 0.0&lt;br /&gt;
  for member in 0...cycle.size do&lt;br /&gt;
    participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
    total_score = participant.review_score&lt;br /&gt;
    deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
    count += 1.0&lt;br /&gt;
  end&lt;br /&gt;
  deviation_score /= count unless count == 0.0&lt;br /&gt;
  deviation_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below are the unit tests for the cycle_similarity_score(cycle) function. The function is very simple, as it doesn't call any other functions. We only need to input the appropriate data and check whether the output is correct. So for each cases, 2 nodes or 3 nodes, I set different cycle as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_similarity_score&amp;quot; do&lt;br /&gt;
    	it &amp;quot;similarity score of 2 node&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;similarity score of 3 node&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 95], [participant3, 85]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10)&lt;br /&gt;
    	end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115101</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115101"/>
		<updated>2018-03-26T06:58:37Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
def cycle_similarity_score(cycle)&lt;br /&gt;
  similarity_score = 0.0&lt;br /&gt;
  count = 0.0&lt;br /&gt;
  for pivot in 0...cycle.size - 1 do&lt;br /&gt;
    pivot_score = cycle[pivot][1]&lt;br /&gt;
    for other in pivot + 1...cycle.size do&lt;br /&gt;
      similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
  end&lt;br /&gt;
  similarity_score /= count unless count == 0.0&lt;br /&gt;
  similarity_score&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_deviation_score(cycle)&lt;br /&gt;
    deviation_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for member in 0...cycle.size do&lt;br /&gt;
      participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
      total_score = participant.review_score&lt;br /&gt;
      deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
    deviation_score /= count unless count == 0.0&lt;br /&gt;
    deviation_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below are the unit tests for the cycle_similarity_score(cycle) function. The function is very simple, as it doesn't call any other functions. We only need to input the appropriate data and check whether the output is correct. So for each cases, 2 nodes or 3 nodes, I set different cycle as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_similarity_score&amp;quot; do&lt;br /&gt;
    	it &amp;quot;similarity score of 2 node&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;similarity score of 3 node&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 95], [participant3, 85]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10)&lt;br /&gt;
    	end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115100</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115100"/>
		<updated>2018-03-26T06:57:42Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Scores */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_deviation_score(cycle)&lt;br /&gt;
    deviation_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for member in 0...cycle.size do&lt;br /&gt;
      participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
      total_score = participant.review_score&lt;br /&gt;
      deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
    deviation_score /= count unless count == 0.0&lt;br /&gt;
    deviation_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The code below are the unit tests for the cycle_similarity_score(cycle) function. The function is very simple, as it doesn't call any other functions. We only need to input the appropriate data and check whether the output is correct. So for each cases, 2 nodes or 3 nodes, I set different cycle as input and check the result of the function.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
context &amp;quot;#cycle_similarity_score&amp;quot; do&lt;br /&gt;
    	it &amp;quot;similarity score of 2 node&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 90]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10.0)&lt;br /&gt;
    	end&lt;br /&gt;
&lt;br /&gt;
    	it &amp;quot;similarity score of 3 node&amp;quot; do&lt;br /&gt;
      		cycle = [[participant1, 100], [participant2, 95], [participant3, 85]]&lt;br /&gt;
      		expect(colcyc.cycle_similarity_score(cycle)).to eq (10)&lt;br /&gt;
    	end&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115099</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115099"/>
		<updated>2018-03-26T06:49:04Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Scores */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_deviation_score(cycle)&lt;br /&gt;
    deviation_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for member in 0...cycle.size do&lt;br /&gt;
      participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
      total_score = participant.review_score&lt;br /&gt;
      deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
    deviation_score /= count unless count == 0.0&lt;br /&gt;
    deviation_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115098</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115098"/>
		<updated>2018-03-26T06:43:27Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be (|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_deviation_score(cycle)&lt;br /&gt;
    deviation_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for member in 0...cycle.size do&lt;br /&gt;
      participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
      total_score = participant.review_score&lt;br /&gt;
      deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
    deviation_score /= count unless count == 0.0&lt;br /&gt;
    deviation_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. similarity&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115097</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115097"/>
		<updated>2018-03-26T06:43:13Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), the similarity score will be (|100-95|+|100-85|+|95-85|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
5. cycle_deviation_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the deviation of one cycle which is the average difference of all participants between the standard review score and the review score from this particular cycle.&lt;br /&gt;
&lt;br /&gt;
For example, if we input a cycle with data like [[participant1, 95], [participant2, 90], [participant3, 91]] (PS: 95 is the score participant1 receives.) and the standard scores for each are 90, 80 and 91, the deviation score will be &lt;br /&gt;
&lt;br /&gt;
(|95-90|+|90-80|+|91-91|)/3 = 5.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_deviation_score(cycle)&lt;br /&gt;
    deviation_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for member in 0...cycle.size do&lt;br /&gt;
      participant = AssignmentParticipant.find(cycle[member][0].id)&lt;br /&gt;
      total_score = participant.review_score&lt;br /&gt;
      deviation_score += (total_score - cycle[member][1]).abs&lt;br /&gt;
      count += 1.0&lt;br /&gt;
    end&lt;br /&gt;
    deviation_score /= count unless count == 0.0&lt;br /&gt;
    deviation_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. similarity&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115093</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115093"/>
		<updated>2018-03-26T04:48:50Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity score which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we have a set of scores like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), so the similarity score will be (|(100-95)|+|(100-85)|+|(95-85)|)/3 = 10.0 .&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. similarity&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115092</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115092"/>
		<updated>2018-03-26T04:47:15Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&lt;br /&gt;
The function below is used to calculate the similarity score which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we have a set of scores like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), so the similarity score will be (|(100-95)|+|(100-85)|+|(95-85)|)/3 = 10.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. similarity&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115091</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115091"/>
		<updated>2018-03-26T04:47:07Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
The function below is used to calculate the similarity score which is the average difference between each pair of scores. &lt;br /&gt;
&lt;br /&gt;
For example, if we have a set of scores like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), so the similarity score will be (|(100-95)|+|(100-85)|+|(95-85)|)/3 = 10.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. similarity&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115090</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115090"/>
		<updated>2018-03-26T04:46:54Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
The function below is used to calculate the similarity score which is the average difference between each pair of scores. &lt;br /&gt;
For example, if we have a set of scores like [[participant1, 100], [participant2, 95], [participant3, 85]] (PS: 100 is the score participant1 receives.), so the similarity score will be (|(100-95)|+|(100-85)|+|(95-85)|)/3 = 10.&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. similarity&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115089</id>
		<title>CSC/ECE 517 Spring 2018 E1814 Write unit tests for collusion cycle.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2018_E1814_Write_unit_tests_for_collusion_cycle.rb&amp;diff=115089"/>
		<updated>2018-03-26T04:20:44Z</updated>

		<summary type="html">&lt;p&gt;Zchen45: /* Functions introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Expertiza Background===&lt;br /&gt;
Expertiza is an opensource web application maintained by students and faculty members of North Carolina State University. Through it students can submit and peer-review learning objects (articles, code, web sites, etc). More information on http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation.&lt;br /&gt;
&lt;br /&gt;
===Project Description===&lt;br /&gt;
Collusion_cycle.rb is a part of the Expertiza project used to calculate potential collusion cycles between peer reviews. Our purpose is to write corresponding unit tests (collusion_cycle_spec.rb) for it.&lt;br /&gt;
&lt;br /&gt;
==Project Details==&lt;br /&gt;
&lt;br /&gt;
===Model introduction===&lt;br /&gt;
&lt;br /&gt;
====Model purpose====&lt;br /&gt;
The file collusion_cycle.rb in app/models is used to calculate potential collusion cycles between peer reviews which means two assignment participants are accidentally assigned to review each other's assignments directly or through a so-called collusion cycle. For example, if participant A was reviewed by participant B, participant B was reviewed by participant C, participant C was reviewed by participant A and all the reviews were indeed finished, then a three nodes cycle exists.&lt;br /&gt;
Cases including two nodes, three nodes and four nodes have been covered in collusion_cycle.rb.&lt;br /&gt;
&lt;br /&gt;
====Functions introduction====&lt;br /&gt;
4. cycle_similarity_score(cycle)&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  def cycle_similarity_score(cycle)&lt;br /&gt;
    similarity_score = 0.0&lt;br /&gt;
    count = 0.0&lt;br /&gt;
    for pivot in 0...cycle.size - 1 do&lt;br /&gt;
      pivot_score = cycle[pivot][1]&lt;br /&gt;
      for other in pivot + 1...cycle.size do&lt;br /&gt;
        similarity_score += (pivot_score - cycle[other][1]).abs&lt;br /&gt;
        count += 1.0&lt;br /&gt;
      end&lt;br /&gt;
    end&lt;br /&gt;
    similarity_score /= count unless count == 0.0&lt;br /&gt;
    similarity_score&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Test Description===&lt;br /&gt;
&lt;br /&gt;
====Cycle Detection====&lt;br /&gt;
1. two-node&lt;br /&gt;
&lt;br /&gt;
2. three node&lt;br /&gt;
&lt;br /&gt;
3. four node&lt;br /&gt;
====Scores====&lt;br /&gt;
1. similarity&lt;br /&gt;
&lt;br /&gt;
2. deviation&lt;br /&gt;
&lt;br /&gt;
===Coverage Result===&lt;br /&gt;
[[File:E1814 Result.png]]&lt;br /&gt;
==Future Work==&lt;br /&gt;
&lt;br /&gt;
==Reference==&lt;br /&gt;
1. rspec *2&lt;br /&gt;
&lt;br /&gt;
2. expertiza *3&lt;/div&gt;</summary>
		<author><name>Zchen45</name></author>
	</entry>
</feed>