CSC/ECE 517 Spring 2018/E1823 Write integration tests for users controller.rb
This wiki page is a description of E1813 final project for Spring 2018, CSC/ECE 517.
Project Statement
Introduction
users_controller.rb is a file under app/controllers that manages different kinds of methods related to users. This project is to write integration tests for users_controller.rb by using rspec, so our goal is to create a file named users_controller_spec.rb under spec/controllers folder and write integration tests to make the path coverage of users_controller.rb more than 90% and achieve the highest possible branch coverage.
All methods used in this file that can render or redirect to one or more user-related views will be thoroughly tested.(16 in total) We do not need to test private or protected methods directly because these methods should be tested when testing other public methods in the same file.
Files Involved
Newly-created file:
spec/users_controller_spec.rb
Tested file:
app/controllers/users_controller.rb
Related view files:
app/views/users/edit.html.erb
app/views/users/keys.html.erb
app/views/users/list.html.erb
app/views/users/list_pending_requested.erb
app/views/users/new.html.erb
app/views/users/request_new.html.erb
app/views/users/show.html.erb
Team Members
1. Sandeep Rajendran(srajend@ncsu.edu)
2. Xiao Ma(xma21@ncsu.edu)
3. Zekun Zhang(zzhang56@ncsu.edu)
4. Zhiyu Chen(zchen45@ncsu.edu)
Functionality of the Controller
Table
Table corresponding to User model has the following attributes: (The unexplained attributes are easy to understand or doesn't make sense here)
1. name
2. crypted_password - It is the password after encrypting.
3. password_salt - It stores the information of the encryption for the password verification.
4. role_id - It is used to distinguish the users as super-administrator, administrator, instructor or student.
5. fullname
6. email
7. parent_id - For an instructor, reference to an entry in administrator table, referring the administrator who accepts for the instructor; otherwise, empty.
8. private_by_default - It is a boolean. Assignments and questionnaire created by the instructor should be private (not visible by others) by default.
9. mru_directory_path - For an instructor, the directory that (s)he was working in the previous time he used the system. This is the path-name relative to the home_directory_path. Empty for a non-instructor.
10. email_on_review - It is a boolean value used to check whether someone else is reviewing my work.
11. email_on_submission - It is a boolean value used to check whether someone else submits work I am assigned to review.
12. email_on_review_of_review - It is a boolean value used to check whether someone else reviews one of my reviews.
13. is_new_user
14. master_permission_granted
15. handle
16. digital_certificate
17. persistence_token
18. timezonepref
19. public_key
20. copy_of_emails - It is a boolean value used to check whether the system will send me copies of emails sent for assignments.
21. institution_id - Reference to an entry in institutions table, referring to the institution at which this user is registered
Methods
1. index
This method is used to list all the users in the database. A permissions check is done first to verify that the current user has permission to view the list of users. If the user is a student, he is redirected away from the page. All other user roles have access to the page.
2. auto_complete_for_user_name
The method finds all users who have names similar to the one being typed and displays only those that have a lower role than the current user. The page is rendered again showing all these suggestions.
3. set_anonymized_view
4. list
5. list_pending_requested
6. show_selection
7. show
8. new
9. request_new
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.
10. create
11. create_requested_user_record
12. create_approved_user
13. edit
resources :users in routing rule maps /users/1/edit (assuming user's id is 1) to edit action in UsersController.
Thus, this edit method is called when accessing user's edit page and will pull the relevant user out of the database via user's id that stored in params[:id].
14. update
resources :users in routing rule makes update action get called when the form in user's edit page is submitted.
This method will first find the relevant user by user's id that stored in params[:id] and then updates the user's information in the database based on the submitted params hash. If the update is successful it shows a success flash and redirects to user's show page otherwise it renders user's edit page.
15. destroy
resources :users in routing rule makes destroy action response to the delete method and thus accomplishing the user deletion.
When this method is called, it will first find the relevant user via user's id that stored in params[:id] and then delete related AssignmentParticipant, TeamsUser and AssignmentQuestionnaire models if any (These models are found through their foregin key: user_id). Finally, the user is deleted from the database and it will show a success flash. If any of the above steps fails, it will throw an error flash.
16. keys
Test Plan
This project aims to writing an integration test for users_controller.rb. There is no this Rspec file exist for this test, so a new test file shall be created and built from scratch. And before writing this test file, some prerequisites must be done. 1. Download and set the Expertiza environment 2. Determine which methods should be tested 3. Define all the conditions needed to be tested for each method
The methods have already been introduced on above, here are the test plan for each method: