-
Notifications
You must be signed in to change notification settings - Fork 1
CMPE 451 Milestone 2 Report
- Table Of Contents
- 1. Executive Summary
- 2. Customer Feedback and Reflections
- 3. Development-Related Changes Made Since Milestone 1 Or Planned For The Future
- 4. List and status of deliverables.
- 5. Progress according to requirements
- 6. API endpoints
- 7. Generated unit test reports
- 8. The general test plan for the project
- 9. Status Of The Features Making Use Of The Annotation Technology
- 10. Plans For Implementing Annotation-Related Functionalities
- 11. Individiual Contibutions
By our second milestone, we successfully implemented several essential features on our game review platform. Initially, we segregated our user base into two categories: basic users and administrators. Administrators possess the capability to create, update, and delete games. We introduced group forums and commenting functionalities, fostering a dynamic social environment where users engage in discussions about games.
One of our pivotal features is the group creation tool, empowering users to form their own groups. Within these groups, members can communicate via dedicated group forums. Additionally, we implemented a voting mechanism for written comments, allowing users to sort comments based on their popularity through votes.
Furthermore, administrators can boost user engagement by introducing tags and achievements for games, groups, and comments. Tags serve as an organizational tool, categorizing content and enabling users to efficiently filter their searches.
The Achievement feature was designed to instill a sense of progress among users and enhance their interaction with the platform. To showcase these achievements, we developed individual profile pages for each user. Within these profiles, users can access information about their achievements, recent activities, and customize their usernames and profile photos.
In summary, we've successfully achieved the envisioned stage of development for our platform.
We listened to the feedback from Milestone 1 and improved our project. First, we added domain specific features to our app that were asked for. Now, our app has achievements that fits different games, making it more fun and personal for users. Also, we fixed the issue with colors not matching in our web and mobile apps. We've made the look more consistent and nice.
In Milestone 2, we continued to make progress on addressing customer feedback and enhancing our project based on the valuable input we received. Here is a summary of the feedback we received during our Milestone 2 presentation and our reflections on each point:
Game Descriptions and User-Friendliness
Feedback: One of the concerns raised was that for users who are not familiar with the games, obtaining information about them can be challenging. The feedback highlighted the need for improved game descriptions and richer content.
Reflection: We acknowledge this feedback and understand the importance of providing clear and informative game descriptions. In response, we will focus on enhancing our game descriptions to make them more comprehensive and user-friendly. This will help both new and experienced users to better understand the games available on our platform.
User Game Creation
Feedback: It was raised that currently, only admins have the capability to create games, and there was a question about why regular users are not allowed to create games.
Reflection: We have taken note of this feedback and will engage in a discussion with our stakeholders regarding the possibility of allowing regular users to create games. We will carefully assess the implications of such a feature and work towards a decision that aligns with our project goals and user needs.
Avatar Implementation
Feedback: There was a difference of opinion regarding the implementation of avatars, and it was suggested that a dedicated meeting should be held to address this matter.
Reflection: We understand that avatars are a topic of interest and contention among our stakeholders. To ensure a thorough discussion and consensus on this feature, we will schedule a dedicated meeting to explore the various perspectives and make an informed decision regarding the integration of avatars into our system.
In conclusion, Milestone 2 has been instrumental in addressing some of the feedback from our previous milestone and identifying new areas for improvement. We remain committed to refining our project based on customer feedback and continuously working towards a more robust and user-centric application. Customer feedback is very valuable to us, and we appreciate customer's ongoing support and collaboration as we strive to deliver an exceptional product.
-
Avatar Feature: We have realized that there is a difference in interpretation between our own understanding and Suzan Hoca's, regarding the avatar feature. Therefore, in the upcoming days, through discussions with Professor Suzan, we may change the avatar feature.
-
Admins capabilities: As we discussed in the second milestone presentation there may be some changes regarding to the capabilities of admin. For example in the future, game creation may not be limited just to admins; regular users could also have a capability to create games or do some other stuffs.
- Snapshot Test: In the future we want to add snapshot tests to ensure the consistency and robustness of our code. Basically snapshot tests are used for deciding whether the components are affected in the expected way or not from the changes in the code. With these addition we are expecting to find the UI error more easily.
- UI Similarity with Mobile: After the first milestone we got a feedback from Suzan Hoca about the non-similarities between frontend and mobile UI. So according to that feedback, now before implementing a feature, we come together with mobile team and talk about the UI to be a consistency. Now our designs look more similar and coherent.
- Considering the Reviews: After the first milestone we got a lot of reviews about the frontend part. Because we had a chance to see those reviews a little bit late(closer to milestone 2), we could not find a time to make some changes according to that. However, after the second milestone we are planning to make some changes especially for the register and login page. Also there may be some changes in the color of the UI.
- Added CI/CD: Even though the implementation has started before the first milestone and the code was already written, the CI/CD only started functioning after first milestone. This made out deployment much more effective. As we didn't need as much time deploying changes manually to our AWS server, we had more time to write code. Also since it runs the unit tests while deploying we were able to be aware of the problems earlier and didn't require to run our unit tests by hand which also consumes time. In addition to that, CI/CD for backend also helped other teams. As we could deploy our changes to server earlier, they had more time to implement the front/mobile side of the functionalities we have implemented.
- Convention of Populating Fields: We have started to populate the objects in our backends. This made it easier for front and mobile teams to access the fields of entities and accelerated their progress. It also helped us because before the milestone 1 we had to go back and change the api if some new feature needed a populated field which we didn't populate before. These changes consumed our time and sometimes broke the connections between backend and front/mobile, which resulted in a lot of bugs. By populating them initially, we no longer require to go back to API and make these changes that causes a lot of problems.
- Increased Communication: We have started to communicate with other teams more actively before implementing our APIs to make sure everybody is on the same page. Previously we had some misunderstandings between some of our members which resulted in more work to do and features running late. Now we are more careful about details and we are making sure there will be no misunderstandings.
- Branch Naming Consistency: Aligned with the broader development team strategy, the mobile team has revised its branch naming conventions to foster synchronization across all teams. Now utilizing a format like "mobile/group-controller," this modification enhances clarity and coherence in collaborative development efforts.
- Folder Structure Optimization: To streamline organization and enhance project maintainability, the mobile team has reconfigured the folder structure. Controllers are now consolidated within a dedicated folder. Furthermore, related files have been grouped together within specific folders, promoting a cohesive and accessible codebase. The placement of the utilities folder within another utilities folder ensures a more organized and hierarchical structure.
- UI Harmony with Frontend: Recognizing the importance of a unified user experience, the mobile team has prioritized aligning the mobile UI with the frontend UI. This involves maintaining consistency in color schemes, button styles, font choices, and other visual elements.
| Deliverable Name | Delivery Status | Due Date | Delivery Date |
|---|---|---|---|
| Project Plan | Delivered | 01.12.2023 | 01.12.2023 |
| Summary of the project status | Delivered | 01.12.2023 | 01.12.2023 |
| Customer Feedback and Reflections | Delivered | 01.12.2023 | 01.12.2023 |
| Weekly Reports | Delivered | 01.12.2023 | 01.12.2023 |
| A Pre-Release Version of Software | Delivered | 27.11.2023 | 27.11.2023 |
| Changes has made since Milestone 1 or planned for the future to improve the development | Delivered | 01.12.2023 | 01.12.2023 |
| Progress According to Requirements | Delivered | 01.12.2023 | 01.12.2023 |
| API Endpoints | Delivered | 01.12.2023 | 01.12.2023 |
| Generated Unit Test Reports | Delivered | 01.12.2023 | 01.12.2023 |
| General Test Plan for the Project | Delivered | 01.12.2023 | 01.12.2023 |
| The status of the features in your software making use of the annotation technology | Delivered | 01.12.2023 | 01.12.2023 |
| Your plans for implementing functionalities associated with annotations | Delivered | 01.12.2023 | 01.12.2023 |
| Individual Contributions | Delivered | 01.12.2023 | 01.12.2023 |
| Milestone Review | Delivered | 01.12.2023 | 01.12.2023 |
Abbreviations:
- NS: Not Started
- IP: In Progress
- C: Completed
- IR: Irrelevant, meaning that this issue has no relevance with that part of the project (back-end, front-end, or mobile)
| Requirement No | Requirement Name | Back-End | Front-End | Mobile | Explanation |
|---|---|---|---|---|---|
| Functional Requirements | |||||
| 1.1 | User Requirements | ||||
| 1.1.1 | Authentication | ||||
| 1.1.1.1 | Sign up | C | C | C | |
| 1.1.1.2 | Login | C | C | C | |
| 1.1.1.3 | Sign Out | C | C | C | |
| 1.1.1.4 | Change Password | C | IP | IP | |
| 1.1.1.5 | Forgot Password | C | C | IP | |
| 1.1.1.6 | Delete Account | C | NS | IP | |
| 1.1.2 | Profile | ||||
| 1.1.2.1 | Profile Page | C | C | C | |
| 1.1.2.2 | Edit Photo, Name, Username | C | C | NS | Can edit photo and username |
| 1.1.2.3 | List the Game They Played | NS | NS | NS | |
| 1.1.2.4 | Put a Link of Their Game Store Accounts | C | C | NS | |
| 1.1.2.5 | Last Activities | C | C | IP | |
| 1.1.2.6 | Achievements | C | C | IP | |
| 1.1.2.7 | Gain Achievements | C | IR | IR | |
| 1.1.3 | Group | ||||
| 1.1.3.1 | Group Creation | C | C | IP | |
| 1.1.3.2 | Group Finding | C | C | IP | |
| 1.1.3.3 | Group Membership | C | C | IP | In mobile, list of groups can be viewed, but filtering functionality is not functional |
| 1.1.3.4 | Group Moderation | C | C | IP | Moderator role is granted to the creator of group and moderators can ban users |
| 1.1.4 | Forum | ||||
| 1.1.4.1 | Forum Posting | C | C | IP | New posts can be create with necessary fields, posts can be voted in front-end and mobile , posts can be deleted and updated in front-end and for all actions back-end keep database updated accordingly |
| 1.1.4.2 | Forum Commenting | C | C | IP | Comments can be created and edited and deleted in front-end, back-end |
| 1.1.4.3 | Forum Search | C | C | IP | Posts can be filtered based on name, tags, and creation date in front-end using implemented endpoint in back-end |
| 1.1.4.4 | Forum Reporting | NS | NS | NS | |
| 1.1.4.5 | Forum Subscription | NS | NS | NS | |
| 1.1.4.6 | Forum Moderation | IP | IP | NS | (For back-end and front-end) posts and comments can be deleted, and uses can be banned |
| 1.1.5 | Game Review | ||||
| 1.1.5.1 | Reviews | C | C | IP | (For back-end and front-end) reviews can be created, edited, deleted and voted |
| 1.1.5.2 | Search | C | C | NS | |
| 1.1.5.3 | Sort | C | C | NS | |
| 1.1.6 | Promotion | ||||
| 1.1.6.1 | Forum Promotion | NS | NS | NS | |
| 1.1.6.2 | Game Promotion | NS | NS | NS | |
| 1.1.7 | Games | ||||
| 1.1.7.1 | Filtering Games by Tag | C | C | IP | |
| 1.1.7.2 | Searching Game by Name | C | C | IP | |
| 1.1.7.3 | Reporting Games | NS | IP | NS | |
| 1.1.7.4 | Achieve Game Specific Info | NS | NS | NS | |
| 1.1.7.5 | See Game-Related Achievements | C | C | IP | |
| 1.1.8 | Admins | ||||
| 1.1.8.1 | Forum | C | C | IP | |
| 1.1.8.2 | Game Review | C | C | NS | (For front-end and back-end) Admins can delete reviews |
| 1.1.8.3 | Games | C | C | IP | Admins can create games and add tags to them |
| 1.1.8.4 | Tags | C | C | IP | |
| 1.2 | System Requirements | ||||
| 1.2.1 | Annotations | NS | NS | NS | |
| 1.2.2 | Group | C | C | IP | System keeps track of user's actions and makes sure that each group has a moderator |
| 1.2.3 | Recommendations | NS | NS | NS | |
| Non-Functional Requirements | |||||
| 2.1 | Privacy | IR | C | IP | (For mobile) platform follows the necessary rules and considers ethical concerns |
| 2.2 | Security | C | IR | IR | |
| 2.3 | Performance & Reliability | IP | IR | IR | Platform has a response time less than 2 seconds and its uptime is above the provided limit |
| 2.4 | Portability | C | C | C | |
| 2.5 | Accessibility | C | C | C | |
| 2.6 | Standards | NS | NS | NS |
For a comprehensive guide and detailed information on the API, visit the following link to the API documentation:
- API Documentation Link: GitHub Wiki - API Documentation
To interact with the API through a user-friendly interface and to explore the available endpoints, use the Swagger UI:
- Swagger Link: Swagger UI
For direct access to the API, use the following link:
- API Link: API Access
Test Case 1: banUser_SuccessfullyBanned
- Functionality Tested: Banning a user in a forum successfully.
- Tested Cases:
- Forum exists, user exists in the forum, and banning is successful.
- Expected Outcome: The user should be successfully banned in the specified forum.
Test Case 2: banUser_ForumNotFound
- Functionality Tested: Handling the case when the specified forum doesn't exist.
- Tested Cases:
- Forum does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 3: unbanUser_SuccessfullyUnbanned
- Functionality Tested: Unbanning a user in a forum.
- Tested Cases:
- Forum exists, user is banned in the forum, and unbanning is successful.
- Expected Outcome: The user should be successfully unbanned in the specified forum.
Test Case 4: unbanUser_ForumNotFound
- Functionality Tested: Handling the case when the specified forum doesn't exist.
- Tested Cases:
- Forum does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 1: createGroup_Success
- Functionality Tested: Creating a group.
- Tested Cases:
- Group title is unique.
- Tags exist and are associated with the group.
- Game exists and is associated with the group.
- Expected Outcome: The group should be successfully created with the specified details.
Test Case 2: createGroup_GroupWithTitleExists_ThrowsBadRequestException
- Functionality Tested: Handling the case when the group title already exists.
- Tested Cases:
- Group with the same title already exists.
- Expected Outcome: BadRequestException should be thrown.
Test Case 3: createGroup_TagNotFound_ThrowsResourceNotFoundException
- Functionality Tested: Handling the case when a specified tag is not found.
- Tested Cases:
- Tag specified in the request is not found.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 4: testGetAllGroups
- Functionality Tested: Retrieving all groups based on filter criteria.
- Tested Cases:
- Filter by title, sort by creation date, descending order, excluding deleted groups.
- Expected Outcome: List of groups should be retrieved based on the specified filter.
Test Case 5: testGetGroupById
- Functionality Tested: Retrieving detailed information about a group by its ID.
- Tested Cases:
- Group ID exists, user is a member, and user has a profile.
- Expected Outcome: Detailed information about the group should be retrieved.
Test Case 6: testGetGroupByIdNotFound
- Functionality Tested: Handling the case when the specified group ID is not found.
- Tested Cases:
- Group with the specified ID does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 7: testDeleteGroupByTitle
- Functionality Tested: Deleting a group by its title.
- Tested Cases:
- Group with the specified title exists.
- Expected Outcome: The group should be successfully deleted.
Test Case 8: testDeleteGroupNotFound
- Functionality Tested: Handling the case when the specified group is not found.
- Tested Cases:
- Group with the specified title does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 9: testUpdateGroup
- Functionality Tested: Updating details of a group.
- Tested Cases:
- Group with the specified ID exists.
- Expected Outcome: The group details should be successfully updated.
Test Case 10: testUpdateGroupNotFound
- Functionality Tested: Handling the case when the specified group is not found.
- Tested Cases:
- Group with the specified ID does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 11: testUpdateGroupInvalidQuota
- Functionality Tested: Handling the case when the new quota is invalid.
- Tested Cases:
- Quota is less than the current number of members.
- Expected Outcome: BadRequestException should be thrown.
Test Case 12: testJoinGroup_Success
- Functionality Tested: Joining a public group.
- Tested Cases:
- Group with the specified ID is public.
- Expected Outcome: User should successfully join the group.
Test Case 13: testJoinPrivateGroup
- Functionality Tested: Handling the case when attempting to join a private group.
- Tested Cases:
- Group with the specified ID is private.
- Expected Outcome: BadRequestException should be thrown.
Test Case 14: testJoinFullGroup
- Functionality Tested: Handling the case when attempting to join a full group.
- Tested Cases:
- Group with the specified ID has reached its quota.
- Expected Outcome: BadRequestException should be thrown.
Test Case 15: testLeaveGroup_Success
- Functionality Tested: Leaving a group.
- Tested Cases:
- User is a member of the group.
- Expected Outcome: User should successfully leave the group.
Test Case 16: testLeaveGroupNotFound
- Functionality Tested: Handling the case when the specified group ID is not found.
- Tested Cases:
- Group with the specified ID does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 17: testApplyGroup
- Functionality Tested: Applying to join a group.
- Tested Cases:
- Group with the specified ID is private.
- Expected Outcome: User should successfully apply to join the group.
Test Case 18: testApplyGroupNotFound
- Functionality Tested: Handling the case when the specified group ID is not found.
- Tested Cases:
- Group with the specified ID does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 19: testApplyGroupPublicGroup
- Functionality Tested: Handling the case when attempting to apply to join a public group.
- Tested Cases:
- Group with the specified ID is public.
- Expected Outcome: BadRequestException should be thrown.
Test Case 20: testApplyGroupAlreadyMember
- Functionality Tested: Handling the case when the user is already a member of the group.
- Tested Cases:
- User is already a member of the group.
- Expected Outcome: BadRequestException should be thrown.
Test Case 21: testApplyGroupBannedMember
- Functionality Tested: Handling the case when the user is banned from the group.
- Tested Cases:
- User is banned from the group.
- Expected Outcome: BadRequestException should be thrown.
Test Case 22: testApplyGroupPendingRequest
- Functionality Tested: Handling the case when the user already has a pending application for the group.
- Tested Cases:
- User already has a pending application for the group.
- Expected Outcome: BadRequestException should be thrown.
Test Case 1: createComment_SuccessfulCreation
- Functionality Tested: Creating a comment on a post successfully.
- Tested Cases:
- Post exists, profile exists, and comment creation is successful.
- Expected Outcome: A new comment should be successfully created and saved.
Test Case 2: createComment_PostNotFound
- Functionality Tested: Handling the case when the specified post doesn't exist.
- Tested Cases:
- Post does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 3: replyComment_SuccessfulReply
- Functionality Tested: Replying to a comment on a post.
- Tested Cases:
- Parent comment exists, profile exists, and reply comment creation is successful.
- Expected Outcome: A reply to the comment should be successfully created and saved.
Test Case 4: editComment_SuccessfulEdit
- Functionality Tested: Editing an existing comment.
- Tested Cases:
- Comment exists and edit operation is successful.
- Expected Outcome: The comment should be successfully edited and updated.
Test Case 5: deleteComment_SuccessfulDeletion
- Functionality Tested: Deleting an existing comment.
- Tested Cases:
- Comment exists and deletion operation is successful.
- Expected Outcome: The comment should be successfully marked as deleted.
Test Case 6: getUserCommentList_SuccessfulRetrieval
- Functionality Tested: Retrieving a list of comments made by a user.
- Tested Cases:
- User has made comments and retrieval operation is successful.
- Expected Outcome: A list of comments made by the user should be successfully retrieved.
Test Case 1: editProfile_SuccessfulEdit
- Functionality Tested: Editing a user's profile successfully.
- Tested Cases:
- Profile exists and edit operation is successful.
- Expected Outcome: The profile should be successfully updated.
Test Case 2: editProfile_ProfileNotFound
- Functionality Tested: Handling the case when the specified profile doesn't exist.
- Tested Cases:
- Profile does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 3: addGameToProfile_SuccessfulAddition
- Functionality Tested: Adding a game to a user's profile.
- Tested Cases:
- Profile and game exist, and addition operation is successful.
- Expected Outcome: The game should be successfully added to the profile.
Test Case 4: removeGameFromProfile_SuccessfulRemoval
- Functionality Tested: Removing a game from a user's profile.
- Tested Cases:
- Profile and game exist, and removal operation is successful.
- Expected Outcome: The game should be successfully removed from the profile.
Test Case 5: getProfile_PrivateProfileAccessDenied
- Functionality Tested: Accessing a private profile by a non-owner and non-admin user.
- Tested Cases:
- Profile is private, and accessed by a non-owner and non-admin user.
- Expected Outcome: BadRequestException should be thrown.
Test Case 6: getProfile_SuccessfulRetrieval
- Functionality Tested: Successfully retrieving a public profile.
- Tested Cases:
- Profile is public and accessible.
- Expected Outcome: The profile should be successfully retrieved.
Test Case 1: testCreateAchievement_GameAchievement_Success
- Functionality Tested: Creating a game achievement successfully.
- Tested Cases:
- Game exists. No existing achievements with the same title.
- Expected Outcome: The game achievement should be successfully created.
Test Case 2: testCreateAchievement_MetaAchievement_Success
- Functionality Tested: Creating a meta achievement successfully.
- Tested Cases:
- No existing achievements with the same title.
- Expected Outcome: The meta achievement should be successfully created.
Test Case 3: testUpdateAchievement_Success
- Functionality Tested: Updating an achievement successfully.
- Tested Cases:
- Achievement exists, and is not deleted.
- Expected Outcome: The achievement should be successfully updated with the new fields.
Test Case 4: testDeleteAchievementById_Success
- Functionality Tested: Deleting an achievement by ID successfully.
- Tested Cases:
- Achievement exists, and is not deleted.
- Expected Outcome: The achievement should be successfully marked as deleted.
Test Case 5: testDeleteAchievement_NotFoundById
- Functionality Tested: Handling the case when the achievement is not found by ID.
- Tested Cases:
- Achievement does not exist or already deleted.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 6: testDeleteAchievementByNameAndGame_Success
- Functionality Tested: Deleting an achievement by name and game successfully.
- Tested Cases:
- Achievement exists, game exists, and the achievement is linked to the given game.
- Expected Outcome: The achievement should be successfully marked as deleted.
Test Case 7: testGrantAchievement_Success
- Functionality Tested: Granting an achievement successfully.
- Tested Cases:
- Achievement and user exist.
- Expected Outcome: The achievement should be successfully granted to the user.
Test Case 1: testGetPostList_Success
- Functionality Tested: Retrieving a list of posts successfully.
- Tested Cases:
- Valid user email is provided, and a list of posts is returned.
- Expected Outcome: A non-null list of GetPostListResponseDto should be returned.
Test Case 2: testGetPostById_Success
- Functionality Tested: Successfully retrieving a post by its ID.
- Tested Cases:
- Post exists and is retrieved successfully for the given ID and user email.
- Expected Outcome: A non-null GetPostDetailResponseDto should be returned.
Test Case 3: testGetPostById_NotFound
- Functionality Tested: Handling the case when the specified post ID doesn't exist.
- Tested Cases:
- Post ID does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 4: testCreatePost_Success
- Functionality Tested: Successfully creating a new post.
- Tested Cases:
- Valid post creation request and user are provided.
- Expected Outcome: A non-null Post object should be returned and saved.
Test Case 5: testEditPost_Success
- Functionality Tested: Successfully editing an existing post.
- Tested Cases:
- Valid post ID, edit request, and user are provided.
- Expected Outcome: The post should be updated with the new details and returned.
Test Case 6: testDeletePost_Success
- Functionality Tested: Successfully deleting an existing post.
- Tested Cases:
- Valid post ID and user are provided.
- Expected Outcome: The post should be marked as deleted and returned.
Test Case 1: getAllVotes_RetrieveAllVotes
- Functionality Tested: Retrieving all votes based on a given filter.
- Tested Cases:
- Filter applied, and votes are retrieved successfully.
- Expected Outcome: A list of votes should be returned, matching the applied filter.
Test Case 2: getVote_VoteFound
- Functionality Tested: Retrieving a specific vote by its ID.
- Tested Cases:
- Vote exists and is successfully retrieved.
- Expected Outcome: The specified vote should be returned.
Test Case 3: addVote_SuccessfullyAdded
- Functionality Tested: Adding a new vote.
- Tested Cases:
- New vote is added successfully.
- Expected Outcome: The new vote should be added and returned.
Test Case 4: addVote_ResourceNotFound
- Functionality Tested: Handling the case when the resource for adding a vote doesn't exist.
- Tested Cases:
- Resource for vote addition does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 1: GetAllReviews_ReturnsAllReviews
- Functionality Tested: Retrieving all reviews based on provided filters.
- Tested Cases:
- Filters set for gameId, reviewedBy, withDeleted, sortBy, and sortDirection.
- Valid return of review list from the repository.
- Expected Outcome: A non-null list of GetAllReviewsResponseDto is returned.
Test Case 2: GetReview_ReturnsReview
- Functionality Tested: Retrieving a single review by its ID.
- Tested Cases:
- Review with the specified ID exists.
- Expected Outcome: A non-null GetAllReviewsResponseDto corresponding to the given ID is returned.
Test Case 3: GetReview_ReviewNotFound
- Functionality Tested: Handling the case when the specified review ID does not exist.
- Tested Cases:
- Review with the specified ID does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 4: AddReview_SuccessfullyAdded
- Functionality Tested: Successfully adding a new review.
- Tested Cases:
- Valid review data is provided.
- Expected Outcome: The review should be successfully added and returned.
Test Case 5: UpdateReview_SuccessfullyUpdated
- Functionality Tested: Successfully updating an existing review.
- Tested Cases:
- Review exists and valid update data is provided.
- Expected Outcome: Review should be successfully updated.
Test Case 6: UpdateReview_ReviewNotFound
- Functionality Tested: Handling the case when the review to update is not found.
- Tested Cases:
- Review with the specified ID does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
Test Case 7: DeleteReview_SuccessfullyDeleted
- Functionality Tested: Successfully deleting a review.
- Tested Cases:
- Review exists for the given ID.
- Expected Outcome: Review should be successfully deleted.
Test Case 8: DeleteReview_ReviewNotFound
- Functionality Tested: Handling the case when the review to delete is not found.
- Tested Cases:
- Review with the specified ID does not exist.
- Expected Outcome: ResourceNotFoundException should be thrown.
The testing plan for the backend part of the project involves different tests to make sure functionality and reliability of the project. JUnit is used for checking individual parts, which means each piece of the project is tested by itself to ensure it performs the way it's supposed to. These tests cover a wide range of scenarios and ensure that each service method behaves as expected under the various inputs provided. Additionally, we use mock data to create pretend information, allowing us to simulate various situations and conditions in unit tests. This helps us see how our project handles different scenarios, ensuring it responds appropriately even before real data is involved. Using mock data also prevents changes to normal data for testing. Postman and Swagger are used to test how different parts of our project communicate with each other. It helps us make sure that data flows smoothly between components, and our API functions correctly. Also, our testing practices extend to database interactions. This involves the execution of tests to confirm that any changes made through the application are accurately reflected in the database, thus preserving data integrity. To further enhance our development process, we actively seek and incorporate feedback from the front-end and mobile teams. This iterative feedback loop allows us to adapt and refine our implementation of endpoints and service methods, ensuring that our backend code remains responsive to the evolving needs and expectations of our collaborative development environment.
The front-end testing plan consists of two types of manual testing to ensure code functionality. Each of these testing phases plays an important role. Pre-Merge Testing focuses on individual features, while Pre-Presentation Testing ensures the collective functioning of all features in a realistic scenario, similar to a final quality assurance before showcasing the product.
When reviewing a pull request (PR), the reviewer downloads the code to their own computer to run it. The main purpose of this is to check if the PR fixes the problems or adds the new features it's supposed to. If the reviewer finds any bugs or problems, they stop the process of adding the code to the main branch. These issues need to be sorted out first before the code can be merged.
This testing is planned one or two days before important milestone presentations. It includes a thorough check of all the features that will be shown during the presentation. If bugs are found, they are treated as urgent. The developer who knows the most about the affected feature is quickly told about the problem. The goal is to fix these issues quickly so that the presentation goes smoothly.
The mobile testing plan consists of manual testing. As one of the parts of the project (the other being front-end), that the user directly interacts, we need to simulate the user behaviour as close as possible, and best way to do it is manually, we deemed. The testing process can be divided to 4 phases:
After the coder of the functionality finished its coding. It first test the Http functions of the related C# class. After thorough testing, it is ensured that these functions indeed make requests as they supposed to do and they handle edge cases and unsuccessful responses. At this stage aldo the view of the respective page is checked and edited if necessary to suit to the decisions user interface and user experience.
After the prefab and its script is tested in isolation, it is tested together with other prefabs and their scripts in the local branch. Some of the functionalities is closely interwoven with other functionalities, thus some errors that are undetectable in the first phase, can be detected here. During this phase, the tester tries to mimic the user behaviour as close as possible, also keeps in mind and tests the edge cases, not only happy paths.
The reviewer of the task merges the changes and the current version of the remote main to her local environment and repeats the above steps. At this stage she tries various other scenarios that may not have come into the mind of the developer. Hence the common proverb: two eyes are better judge than a single eye.
After the reviewer has tested the newly developed code, it is merged to the main and pushed to the remote.
In the days leading to the milestone, the functionalities of the mobile part of the project is tested repeatedly and excessively. This is made to ensure that previously working parts are still working and a beautiful user experience is provided. As a last part of this testing phase, builds of the project is created, and the mobile application is tested on Android phones.
As of now, unfortunately we don’t have any feature that is making use of the annotations. Despite assigning research tasks on annotations to a couple of teammates for last two weeks, we couldn’t find time to delve deeper on the subject. This was mainly due to our focus on developing the core functionalities of the platform.
Regarding our plans for implementing functionalities associated with annotations, our first step involves dedicating time to understand annotations. We’re going to achieve this by studying the Web Annotation Data Model and reviewing relevant examples. Once we are comfortable with the annotations and we can agree upon a common approach we’re going to proceed with their implementation and integration into both our games and posts. Later we can utilize these annotations to strengthen links between different games, calculating similarities.
Cmpe 352
Cmpe 451
Cmpe 352
Milestone 1
Final Milestone
Milestone 1
Milestone 2
Final Milestone
- Authentication Mockup
- Forum Mockup
- Game Reviews Mockup
- Games Page Mockup
- Group Page Mockup
- Home Page Mockup
- Profile Page Mockup
- Unregistered User Scenario: Sign Up
- Unregistered User Scenario: Search for a Game and Browse the Game Forum
- Registered User Scenario: Create Post in a Game Forum
- Registered User Scenario: Search For Groups and Join A Group
📝 RAM
- Issue Template
- Personal Information Template
- Meeting Note Template
- Contributions Template
- API Documentation Template
API Documentation for Practice App
- Top Games
- Yugioh Card
- Hearthstone Card
- Games By User
- Game Reviews
- Games By Genre
- Games By Category
- Game Suggestions
- Esport Tournaments
- Achievement By Game Id
- Rock Paper Scissors
- Game By Deal