CSC/ECE 517 Spring 2023 -E2339. Reimplement signed up teams controller and sign up topics controller.rb: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(37 intermediate revisions by 2 users not shown)
Line 1: Line 1:


== '''Introduction''' ==
== '''Project Overview''' ==
The content of this page provides details on the adjustments needed for the "sign_up_topics controller" and the development of a new "signed_up_teams_controller" in the process of re-implementing the expertiza based open-source software project.
This project is really number E2340 (not E2339!).
=== '''Background''' ===
The signup_sheet_controller in expertiza is responsible for managing the signup sheet for an assignment. The controller includes functions to add, edit, and delete topics for the assignment, as well as perform team and deadline management functions. One important feature of the signup sheet is the ability for teams to sign up for topics. The controller includes methods to handle this functionality, including checking if there are available slots for a particular topic, adding the team to the waitlist if there are no available slots, and updating the signup sheet accordingly. In addition to signing up for topics, teams also have the ability to drop a topic. If a team drops a topic and there are teams on the waitlist for that topic, the first team on the waitlist (based on the creation date) will be automatically signed up for the topic. The controller includes methods to populate the objects needed for the signup sheet for a particular assignment. This could include retrieving information about the assignment, the topics, and the teams that have signed up for each topic. Most importantly, only instructors can create, update and delete the topics.
 
=== '''Project Objective''' ===
Our task is to reimplement these major functionalities for signing up topics and teams in Rails API which will then be consumed by a React based frontend. The current business logic in the controller is complex and involves multiple things in a single function which contradicts Single-Responsibility principle. We decided to split the existing controller into two separate controllers, one for signup_topics and one for signed_up_teams. Some of the groundwork required for signup_topics controller is already completed previously. We will be working on finetuning the signup_topics controller further by writing robust tests and making the code more DRY and in alignment with Ruby guidelines. Additionally, we will be implementing the signed_up_teams controller to address the association between topics and teams.


== '''Implemented Work''' ==
=== '''Previous Work''' ===
As a component of program 3, it was agreed to partition the sign-up topic controller in Expertiza into two distinct controllers, namely "sign_up_topics_controller" and "signed_up_teams_controller". The implementation for the former has already been executed.The diagram presented below offers a visual depiction of the previously mentioned details.
The exisiting signup_sheet_controller from the original expertiza repo is split into two controllers, signup_topics and signed_up_teams. The foundation work is done on signup_topics controller which can be found at (https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2316._Reimplement_sign_up_sheet_controller.rb)
<br/>


[[File:Achetwa diag.png]]
[[File:Achetwa diag.png]]
<br/>


== '''Design Improvements and Ongoing work for "sign_up_topics controller"''' ==


1. Add filter to the index method : At present, the "index" method used to display all the available topics lacks the capability to filter by assignment ID. Although the existing implementation includes a filter to remove topics, the plan is to either relocate or establish a comparable filter for the "index" method to enable the listing of only selected topics.
== '''Project Implementation''' ==
=== '''Design Improvements for "sign_up_topics controller"''' ===


Below is a code snippet showing the two functions :
'''Improvement 1:'''<br/>
We propose to add the filtering functionality to the existing index method of the sign_up_topics. The filter functionality will allow users to retrieve a subset of sign_up_topics based on certain criteria such as assignment ID and topic identifiers. This will improve the usability of the API and provide more flexibility to the user in retrieving data.


== '''Expertiza Overview''' ==
'''Rationale:''' <br/>
Expertiza is a comprehensive and open-source assignment and project management portal that supports collaborative learning and feedback between instructors and students. Developed on the Ruby on Rails framework, this web application is designed to provide a range of features and capabilities to create and customize assignments, quizzes, topics, and assignment groups. Expertiza also enables students to form teams and work together on various projects while providing a complete mechanism for peer review and feedback on other groups and teammates' submissions. Developed and maintained by students and faculty at NC State, Expertiza is a versatile and well-developed application that can handle all types of assignments, and its full functionality can be explored in the Expertiza wiki.
The index method currently retrieves all sign_up_topics and returns them in the response. However, in many cases, the user may only want to retrieve a subset of sign_up_topics that meet certain criteria. By adding the filter functionality, users can retrieve the data they need more efficiently and effectively. Additionally, the filter functionality will follow a RESTful approach and be consistent with the existing API design. It will allow users to specify the filtering criteria as query parameters in the URL, which is a common convention in RESTful APIs.
By making this decision, we don't have to expose a separate endpoint for the filtering functionality like it is being currently done. Furthermore, the filter functionality will be implemented using a private method get_selected_topics that uses the where method to retrieve the desired sign_up_topics based on the filtering criteria. The resulting data will be returned in the response as a JSON object.
Overall, the addition of the filtering functionality to the index method will enhance the usability and flexibility of the API, and will be consistent with RESTful API design principles.


== '''Project Overview''' ==
{| class="wikitable"
|-
! style="text-align:center;"| method name
! style="text-align:center;"| description
! style="text-align:center;"| improvement
|-
| filter
| filters topics based on assignment id (required) and topic identifiers (optional)
| move to index
|}


'''Current implementation:'''<br/>
'''
  # GET /sign_up_topics
  def index
    @sign_up_topics = SignUpTopic.all
    render json: @sign_up_topics
  end


The signup_sheet_controller in expertiza is responsible for managing the signup sheet for an assignment.
  def filter
The controller includes functions to add, edit, and delete topics for the assignment, as well as perform team and deadline management functions. One important feature of the signup sheet is the ability for teams to sign up for topics. The controller includes methods to handle this functionality, including checking if there are available slots for a particular topic, adding the team to the waitlist if there are no available slots, and updating the signup sheet accordingly. In addition to signing up for topics, teams also have the ability to drop a topic. If a team drops a topic and there are teams on the waitlist for that topic, the first team on the waitlist (based on the creation date) will be automatically signed up for the topic. The controller includes methods to populate the objects needed for the signup sheet for a particular assignment. This could include retrieving information about the assignment, the topics, and the teams that have signed up for each topic. Most importantly, only instructors can create, update and delete the topics. 
    get_selected_topics
    render json: {message: 'All selected topics have been loaded successfully.', sign_up_topics: @stopics}, status: 200
  end


== '''Problem Statement''' ==
  private
  def get_selected_topics
    if params[:assignment_id].nil?
      render json: {message: 'Assignment ID is required!' }, status: :unprocessable_entity
    elsif params[:topic_ids].nil?
      @stopics = SignUpTopic.where(assignment_id: params[:assignment_id])
    else
      @stopics = SignUpTopic.where(assignment_id: params[:assignment_id], topic_identifier: params[:topic_ids])
    end
  end
'''


Our task is to reimplement these major functionalities for signing up topics and teams in Rails API which will then be consumed by a React based frontend. The current business logic in the controller is complex and involves multiple things in a single function which contradicts Single-Responsibility principle. In this project, in the first phase, we decided to work on simplifying the logic and extracting only the required functionalities which are being currently used extensively.
'''Improved implementation:'''<br/>
'''
Will be added in the future once we implement it. <br/>


== '''Design Decisions''' ==
'''




<br>
----
'''''1. Split the signup_sheet controller into signup_teams controller and signup_topics controller.'''''
 
'''Rationale'''<br>


Splitting a monolithic controller into multiple controllers can help to isolate specific areas of functionality. This can make the codebase easier to navigate and modify in the future. Smaller controllers can often lead to better performance, especially in cases where the original monolithic controller is handling too much traffic or too many requests at once. Splitting the controller into smaller, more focused controllers can help to distribute traffic more evenly and improve overall application performance. By breaking down a monolithic controller into smaller controllers, we can create more focused unit tests that can help to catch bugs and improve overall code quality. When multiple developers are working on a project, it can be easier to collaborate when the codebase is split into smaller, more focused controllers.
'''Improvement 2:'''<br/>
We also propose to add the filtering functionality for the deleting of topics to the existing destroy method of the sign_up_topics same as for the index method.


'''Work Done''' <br>
'''Rationale:'''<br/>
The "delete_filter" method and the "destroy" method both perform similar actions, which is to delete a sign up topic. Therefore, it makes sense to combine them into a single method to reduce code duplication and improve the maintainability of the codebase.


The signup_topics controller deals with the basic CRUD operations. It allows only the instructor to create, read, update and delete the topics for a particular assignment. <br>
By merging the two methods, we can eliminate the need for a separate route and controller action to handle the deletion of sign up topics based on specific criteria. The combined method can handle all types of deletion requests, whether it is deleting a single sign up topic or multiple topics based on specific criteria.


{| class="wikitable"
Furthermore, by consolidating the functionality into a single method, we can reduce the complexity of the controller and make it easier to understand and maintain in the future. This simplification can also lead to improved performance and reduced resource consumption, as fewer controller actions need to be executed to achieve the same result.
| style="text-align:center;"| '''method name'''
| style="text-align:center;"| '''description'''
|-
| index
| returns all the topics 
|-
| create
| creates the new topic
|-
| update
| updates the topic with newly provided params
|-
| destroy
| destroys the topic info for given topic id
|}


Additionally, it supports the following methods from the original implementation to filter and delete multiple topics at once.
{| class="wikitable"
{| class="wikitable"
| style="text-align:center;"| '''method name'''
| style="text-align:center;"| '''description'''
|-
|-
| filter
! style="text-align:center;"| method name
| filters topics based on assignment id (required) and topic identifiers (optional)
! style="text-align:center;"| description
! style="text-align:center;"| improvement
|-
|-
| delete_filter
| delete_filter
| deletes topics based on assignment id (required) and topic identifiers (optional)
| deletes topics based on assignment id (required) and topic identifiers (optional)
| move to destroy
|}
|}


Some more helper methods <br>
'''Current implementation:'''<br/>
{| class="wikitable"
'''
| style="text-align:center;"| '''method name'''
  def destroy
| style="text-align:center;"| '''description'''
    if @sign_up_topic.destroy
|-
      render json: {message: "The topic has been deleted successfully. "}, status: 200
| set_sign_up_topic
    else
| loads the signup topic for given topic id.
      render json: @sign_up_topic.errors, status: :unprocessable_entity
|-
    end
| sign_up_topic_params
  end
| decides the required parameters for a signup topic
 
|}
  def delete_filter
    #filters topics based on assignment id (required) and topic identifiers (optional)
    get_selected_topics
    @stopics.each(&:delete)
    render json: {message: 'All selected topics have been deleted successfully.', sign_up_topics: @stopics }, status: 200
  end
'''
 
'''Improved implementation:'''<br/>
'''
Will be added in the future once we implement it. <br/>
'''
<br/>


''Note: signup_team_controller will be implemented in the next phase.''


'''design'''
[[File:Achetwa_diag.png]]
----
----


<br>
'''Improvement 3:'''<br/>
'''''2. Move business logic from controller to model.'''''
Making the tests thorough and robust. Check the changes in data after performing operations and also checking the valid response statuses.
 
'''Rationale:'''<br/>
1. The existing tests will need to be modified to reflect the changes mentioned in aforementioned design decisions. That includes getting rid of the tests for filter and delete_filter endpoints. The existing tests for GET and DELETE will be modified accordingly.
 
2. We will add appropriate response statuses to each test. For e.g., returning '204 No Content' for the delete test when the topic is deleted successfully rather than using '200 OK' status.
 
3. We will make each test robust by making sure the changes after performing certain operations are getting reflected. For e.g., Testing that the response body does not contain the deleted sign-up topic data after the delete request is successful.
 
'''Current implementation:'''<br/>
 
Current implementation of DELETE test:


'''Rationale'''<br>
[[File:Screenshot 2023-04-07 at 6.49.38 PM.png]]


The Model-View-Controller (MVC) design pattern separates the application into three main components: models, views, and controllers. The controller's job is to handle user input and interaction, while the model's job is to represent the data and perform operations on it. By moving the business logic to the models, we can achieve a better separation of concerns and keep the controller's responsibility limited to handling user input.
'''Improved implementation:'''<br/>
Moving the business logic to the models can also improve the scalability of the application. By separating the business logic from the controller, we can avoid having a monolithic controller that performs many different operations (which was the case for earlier expertiza implementation). This can help to improve performance and make the application more scalable.
'''
Will be added in the future once we implement it. <br/>
'''


'''Work Done''' <br>
=== '''Signed Up teams Controller''' ===
Since this project involves reimplementing the controller from the ground up, all the complex business logic that was making the signup sheet controller bulkier has been removed. In this first phase, the controller has minimum viable methods to make the core functionalities of the signup sheet like CRUD operation on the topics and other additional methods required by the instructor.
In the next, phase the additional required business logic will be implemented in the respective models as per the additional requirements. <br>
<br>


* In the original implementation, the list method  is too crowded with populating the required data from the model and also doing some checks on topic deadlines. Those checks can be moved to the model which will make the list method a Single Responsibility method which populates the required topic details.
The signed up teams controller will be having the following functionalities
* save_topic_deadlines is one of the gigantic method doing lot of things related to setting deadlines which should be done thorugh the deadline models


Index - this will filter the topics based on the team ID.


----
Create - this will create a sign up team.


<br>
Update - this will update the signed up team.
'''''3. Delete irrelevant/redundant methods from the controller.'''''


'''Rationale'''<br>
Delete - this will destroy the signed up team.


Controllers are responsible for handling incoming requests and managing the flow of data between the model and the view. If a controller has methods that are not being used or are redundant, it can make the codebase harder to navigate and more difficult to maintain. Deleting unused or redundant methods from a controller can help to simplify the codebase and reduce the risk of errors. It can also make it easier for other developers to understand the code and make changes to it in the future.
A basic E/R Diagram for the same is shown :


'''Work Done''' <br>
[[File:ER ACHETWA.png]]
There are currently so many methods in the signup_sheet_controller which are absolute and are not being used for many years. So, we decide to remove those methods and cleanup up the controllers. Since, this is a reimplementation of the controller, we didn't include those absolute functions in our newer implementation.


{| class="wikitable"
| style="text-align:center;"| '''method removed'''
| style="text-align:center;"| '''reason'''
|-
| ad_info
| the method was earlier used for broadcasting an ad for team member which is not being done for quite a while now. 
|-
| set_priority
| it was used as helper function for bidding on the topics which is not being used currently.
|-
| list
| some part of this method which deals with the bidding logic will be removed.
|}


== '''Testing''' ==


For testing the functionality of the controller the swagger API has been used. The tests covered are to perform create, read, update and delete operations as a part of the sign up topic controller. Other tests covered are to list all topics, delete all selected topics and delete all topics given assignment.
== '''Test Plan''' ==
Testing each functionality - '''The tests require injection of data into the data base and rswag spec running'''


1. Setting up rswag -  the following command needs to be run after setting up the project - ''rails rswag:specs:swaggerize''
=== '''Testing for signup_topics''' ===


2. Injecting dummy data into the database - The sign up topic table and the assignment table needs dummy entries. The easiest way to do the same is to load the project and add them manually. The assignment table and the sign_up_topic table need proper population for the tests to work.
1. Test index action: <br/>
Test that it returns a JSON response with HTTP status code 200. <br/>
Test that it returns all sign-up topics in the database. <br/>
Test create action: <br/>


3. Once the rswag command from step 1 has been run, the rswag testing environment can be loaded using the local server by the following link - <host-name>/api-docs. There are added roles test as a part of the API which can be ignored.
2. Test that it creates a new sign-up topic in the database with valid parameters. <br/>
Test that it creates a new sign-up topic in the database with valid parameters. <br/>
Test that it returns a JSON response with HTTP status code 201. <br/>
Test that it returns an error message with HTTP status code 422 when invalid parameters are passed. <br/>


'''TEST 1'''
3. Test update action: <br/>
Create topic - In the rswag API the test can be conducted, using the assignment ID one can create a new topic, the topic name and assignment ID is a unique combination and the test fails if the same combination is used for testing. The entries entered to test the API must be a part of the database.
Test that it updates an existing sign-up topic in the database with valid parameters. <br/>
Test that it returns a JSON response with HTTP status code 200. <br/>
Test that it returns an error message with HTTP status code 422 when invalid parameters are passed. <br/>


'''TEST 2'''
4. Test destroy action: <br/>
Update a topic - The required input is the ID of the topic, when the test is executed any change made to the Topic parameters is reflected in the test, flashing a message for success.
Test that it deletes an existing sign-up topic from the database with a valid ID. <br/>
Test that it returns a JSON response with HTTP status code 200. <br/>
Test that it returns an error message with HTTP status code 422 when an invalid ID is passed. <br/>


'''TEST 3'''
Delete a topic -  The input for this test is the just the topic and the corresponding topic can be deleted. If a topic which does not exist is tried to be deleted an error pops up.


'''TEST 4'''
=== '''Testing for signed_up_teams''' ===
Load all selected topics based on assignment ID and Topic ID - Based on the assignment ID and unique topics identifier which is passed as an input to the API , all corresponding topics unique to that entry are returned. If the topics for the entered combination does not exist the test will return a blank list.


'''TEST 5'''
1. Test that the index action returns a JSON response with HTTP status code 200. <br/>
Delete all selected topics based on assignment ID and Topic ID - This test is similar to test 4. Once given the combination ->topics are deleted. After deletion if test 4 is again implemented it will return a blank list, this validates the working of the functionalities.
Test that it returns all sign-up teams in the database. <br/>
Test that it returns the sign-up team with the requested ID. <br/>
Test that it returns an error message with HTTP status code 404 when an invalid ID is passed. <br/>


2. Test that the create action creates a new sign-up team in the database with valid parameters. <br/>
Test that it returns a JSON response with HTTP status code 201. <br/>
Test that the sign-up team is saved in the database. <br/>
Test that it returns an error message with HTTP status code 422 when invalid parameters are passed. <br/>


Demo snippet of signup_topic table for testing
3. Test that the update action updates an existing sign-up team in the database with valid parameters. <br/>
Test that it returns a JSON response with HTTP status code 200. <br/>
Test that the sign-up team is updated in the database. <br/>
Test that it returns an error message with HTTP status code 422 when invalid parameters are passed. <br/>


[[File:Signup table structure.png]]
4. Test that the destroy action deletes an existing sign-up team from the database with a valid ID. <br/>
Test that it returns a JSON response with HTTP status code 200. <br/>
Test that the sign-up team is deleted from the database. <br/>
Test that it returns an error message with HTTP status code 404 when an invalid ID is passed. <br/>


Demo snippet of the testing page
== '''Future Plan''' ==
The proposed implementation approach will prioritize the following hierarchy:


[[File:achetwa_new.png]]
1.The sign up topic controller will be refined to facilitate smooth merging into the code.


== '''Future Work''' ==
2. Development efforts will be directed towards the signed up teams controller, utilizing the aforementioned design as a foundation. While the design may undergo revisions, the core functionalities will remain consistent.


1. The sign up sheet controller has been split into two controllers sign up topics and sign up teams, the functionality for the sign up teams have been drafted but need to be tested and need some updates. <br>
3. Finally, the front-end will be implemented.
2. Create a react frontend to view the response returned by the new controllers<br>


== '''Relevant Links''' ==
== '''Relevant Links (previous implementation)''' ==


Github Repository: https://github.com/anuj672/reimplementation-back-end <br>
Github Repository: https://github.com/anuj672/reimplementation-back-end <br>
Line 177: Line 221:
Video1 : https://youtu.be/ZAh80Gj5A5U <br>
Video1 : https://youtu.be/ZAh80Gj5A5U <br>
Video2: https://youtu.be/1IFXC7DAljI <br>
Video2: https://youtu.be/1IFXC7DAljI <br>
deployed version: http://152.7.179.176:8080/api-docs/index.html


== '''Group''' ==
== '''Group''' ==

Latest revision as of 13:23, 6 May 2023

Project Overview

This project is really number E2340 (not E2339!).

Background

The signup_sheet_controller in expertiza is responsible for managing the signup sheet for an assignment. The controller includes functions to add, edit, and delete topics for the assignment, as well as perform team and deadline management functions. One important feature of the signup sheet is the ability for teams to sign up for topics. The controller includes methods to handle this functionality, including checking if there are available slots for a particular topic, adding the team to the waitlist if there are no available slots, and updating the signup sheet accordingly. In addition to signing up for topics, teams also have the ability to drop a topic. If a team drops a topic and there are teams on the waitlist for that topic, the first team on the waitlist (based on the creation date) will be automatically signed up for the topic. The controller includes methods to populate the objects needed for the signup sheet for a particular assignment. This could include retrieving information about the assignment, the topics, and the teams that have signed up for each topic. Most importantly, only instructors can create, update and delete the topics.

Project Objective

Our task is to reimplement these major functionalities for signing up topics and teams in Rails API which will then be consumed by a React based frontend. The current business logic in the controller is complex and involves multiple things in a single function which contradicts Single-Responsibility principle. We decided to split the existing controller into two separate controllers, one for signup_topics and one for signed_up_teams. Some of the groundwork required for signup_topics controller is already completed previously. We will be working on finetuning the signup_topics controller further by writing robust tests and making the code more DRY and in alignment with Ruby guidelines. Additionally, we will be implementing the signed_up_teams controller to address the association between topics and teams.

Previous Work

The exisiting signup_sheet_controller from the original expertiza repo is split into two controllers, signup_topics and signed_up_teams. The foundation work is done on signup_topics controller which can be found at (https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2316._Reimplement_sign_up_sheet_controller.rb)



Project Implementation

Design Improvements for "sign_up_topics controller"

Improvement 1:
We propose to add the filtering functionality to the existing index method of the sign_up_topics. The filter functionality will allow users to retrieve a subset of sign_up_topics based on certain criteria such as assignment ID and topic identifiers. This will improve the usability of the API and provide more flexibility to the user in retrieving data.

Rationale:
The index method currently retrieves all sign_up_topics and returns them in the response. However, in many cases, the user may only want to retrieve a subset of sign_up_topics that meet certain criteria. By adding the filter functionality, users can retrieve the data they need more efficiently and effectively. Additionally, the filter functionality will follow a RESTful approach and be consistent with the existing API design. It will allow users to specify the filtering criteria as query parameters in the URL, which is a common convention in RESTful APIs. By making this decision, we don't have to expose a separate endpoint for the filtering functionality like it is being currently done. Furthermore, the filter functionality will be implemented using a private method get_selected_topics that uses the where method to retrieve the desired sign_up_topics based on the filtering criteria. The resulting data will be returned in the response as a JSON object. Overall, the addition of the filtering functionality to the index method will enhance the usability and flexibility of the API, and will be consistent with RESTful API design principles.

method name description improvement
filter filters topics based on assignment id (required) and topic identifiers (optional) move to index

Current implementation:

 # GET /sign_up_topics
 def index
   @sign_up_topics = SignUpTopic.all
   render json: @sign_up_topics
 end
 def filter
   get_selected_topics
   render json: {message: 'All selected topics have been loaded successfully.', sign_up_topics: @stopics}, status: 200
 end
 private
 def get_selected_topics
   if params[:assignment_id].nil?
     render json: {message: 'Assignment ID is required!' }, status: :unprocessable_entity
   elsif params[:topic_ids].nil?
     @stopics = SignUpTopic.where(assignment_id: params[:assignment_id])
   else
     @stopics = SignUpTopic.where(assignment_id: params[:assignment_id], topic_identifier: params[:topic_ids])
   end
 end

Improved implementation:
Will be added in the future once we implement it.



Improvement 2:
We also propose to add the filtering functionality for the deleting of topics to the existing destroy method of the sign_up_topics same as for the index method.

Rationale:
The "delete_filter" method and the "destroy" method both perform similar actions, which is to delete a sign up topic. Therefore, it makes sense to combine them into a single method to reduce code duplication and improve the maintainability of the codebase.

By merging the two methods, we can eliminate the need for a separate route and controller action to handle the deletion of sign up topics based on specific criteria. The combined method can handle all types of deletion requests, whether it is deleting a single sign up topic or multiple topics based on specific criteria.

Furthermore, by consolidating the functionality into a single method, we can reduce the complexity of the controller and make it easier to understand and maintain in the future. This simplification can also lead to improved performance and reduced resource consumption, as fewer controller actions need to be executed to achieve the same result.

method name description improvement
delete_filter deletes topics based on assignment id (required) and topic identifiers (optional) move to destroy

Current implementation:

 def destroy
   if @sign_up_topic.destroy
     render json: {message: "The topic has been deleted successfully. "}, status: 200
   else
     render json: @sign_up_topic.errors, status: :unprocessable_entity
   end
 end
 def delete_filter
   #filters topics based on assignment id (required) and topic identifiers (optional)
   get_selected_topics
   @stopics.each(&:delete)
   render json: {message: 'All selected topics have been deleted successfully.', sign_up_topics: @stopics }, status: 200
 end

Improved implementation:
Will be added in the future once we implement it.



Improvement 3:
Making the tests thorough and robust. Check the changes in data after performing operations and also checking the valid response statuses.

Rationale:
1. The existing tests will need to be modified to reflect the changes mentioned in aforementioned design decisions. That includes getting rid of the tests for filter and delete_filter endpoints. The existing tests for GET and DELETE will be modified accordingly.

2. We will add appropriate response statuses to each test. For e.g., returning '204 No Content' for the delete test when the topic is deleted successfully rather than using '200 OK' status.

3. We will make each test robust by making sure the changes after performing certain operations are getting reflected. For e.g., Testing that the response body does not contain the deleted sign-up topic data after the delete request is successful.

Current implementation:

Current implementation of DELETE test:

Improved implementation:
Will be added in the future once we implement it.

Signed Up teams Controller

The signed up teams controller will be having the following functionalities

Index - this will filter the topics based on the team ID.

Create - this will create a sign up team.

Update - this will update the signed up team.

Delete - this will destroy the signed up team.

A basic E/R Diagram for the same is shown :


Test Plan

Testing for signup_topics

1. Test index action:
Test that it returns a JSON response with HTTP status code 200.
Test that it returns all sign-up topics in the database.
Test create action:

2. Test that it creates a new sign-up topic in the database with valid parameters.
Test that it creates a new sign-up topic in the database with valid parameters.
Test that it returns a JSON response with HTTP status code 201.
Test that it returns an error message with HTTP status code 422 when invalid parameters are passed.

3. Test update action:
Test that it updates an existing sign-up topic in the database with valid parameters.
Test that it returns a JSON response with HTTP status code 200.
Test that it returns an error message with HTTP status code 422 when invalid parameters are passed.

4. Test destroy action:
Test that it deletes an existing sign-up topic from the database with a valid ID.
Test that it returns a JSON response with HTTP status code 200.
Test that it returns an error message with HTTP status code 422 when an invalid ID is passed.


Testing for signed_up_teams

1. Test that the index action returns a JSON response with HTTP status code 200.
Test that it returns all sign-up teams in the database.
Test that it returns the sign-up team with the requested ID.
Test that it returns an error message with HTTP status code 404 when an invalid ID is passed.

2. Test that the create action creates a new sign-up team in the database with valid parameters.
Test that it returns a JSON response with HTTP status code 201.
Test that the sign-up team is saved in the database.
Test that it returns an error message with HTTP status code 422 when invalid parameters are passed.

3. Test that the update action updates an existing sign-up team in the database with valid parameters.
Test that it returns a JSON response with HTTP status code 200.
Test that the sign-up team is updated in the database.
Test that it returns an error message with HTTP status code 422 when invalid parameters are passed.

4. Test that the destroy action deletes an existing sign-up team from the database with a valid ID.
Test that it returns a JSON response with HTTP status code 200.
Test that the sign-up team is deleted from the database.
Test that it returns an error message with HTTP status code 404 when an invalid ID is passed.

Future Plan

The proposed implementation approach will prioritize the following hierarchy:

1.The sign up topic controller will be refined to facilitate smooth merging into the code.

2. Development efforts will be directed towards the signed up teams controller, utilizing the aforementioned design as a foundation. While the design may undergo revisions, the core functionalities will remain consistent.

3. Finally, the front-end will be implemented.

Relevant Links (previous implementation)

Github Repository: https://github.com/anuj672/reimplementation-back-end
Pull Request: https://github.com/expertiza/reimplementation-back-end/pull/25
Video1 : https://youtu.be/ZAh80Gj5A5U
Video2: https://youtu.be/1IFXC7DAljI

Group

Mentored by

Krishna Saurabh Vankadaru

Group members

Anuj Naresh Chetwani

Indira Pimpalkhare

Tejas Prabhu