Lab 8

[kristinatrajkovski]

We need to create a checklist of things needed to be done for the last milestone.

We need to make sure to specify acceptance criteria and examples of functioning features!

Checklist items:

• Primary features (e.g. semantic search, user management),
• Domain-specific features (e.g. why they're specific, how they're implemented),
• API and its documentation (e.g. endpoints, expected inputs, outputs),
• Standard(s) being followed (e.g. its documentation, implementation),
• Testing strategies (e.g. unit test coverage, integration testing, tools).

Make sure to link your future related work to this PR!

[kristinatrajkovski]

Testing Strategies Checklist:

• Unit test enhancement:

• Missed unit tests must be written for mobile's front end.
  Acceptance criteria: Every written function in the mobile front end has a corresponding unit test which passes.
  Example: Mobile front end login test written in this commit. The newly written tests must be similar with a corresponding function.

• Missed unit tests must be written for web's front end.
  Acceptance criteria: Every written function in the web front end has a corresponding unit test which passes.
  Example: Web front end Search Results test written in this commit

• Update back end unit tests written in this PR
  Acceptance criteria: the tests currently failing accomodate the new version of the back end, all of the functions in the back end (all end points) have at least one unit test that checks the functionality.
  Example: Back end test for Wikidata search and results written in [this commit].

• Integration tests:

• Integration tests covering the functionalities in mobile front end must be written
  Acceptance criteria: Every written function in the mobile front end is a part of an integration test (together with other related functions in a specific scenario) which passes.
  Example: Similar test to the one in back end in this commit. Make sure to incorporate more than one function in a scenario as in example.

• Integration tests covering the functionalities in web front end must be written
  Acceptance criteria: Every written function in the webfront end is a part of an integration test (together with other related functions in a specific scenario) which passes.
  Example: Similar test to the one in back end in this commit. Make sure to incorporate more than one function in a scenario as in example.

• Integration tests covering the functionalities in back end must be written
  Acceptance criteria: Every written function in back end is a part of an integration test (together with other related functions in a specific scenario) which passes.
  Example: Similar test to the one in back end in this commit. Make sure to incorporate more than one function in a scenario as in example.

[halil-karabacak]

4. Standard's Being Followed

- As a team, we decided to implement W3C standard "Annotation" .

• For the final milestone, front-end require a little more work, we have decided to implement annotation functionality in post detail page as well. It requires more work and will be planned accordingly. Similar to web app, mobile app also requires post detail page to have annotation support.
  Acceptance criteria: Users should be able to share annotations in post detail as well.
  Example: Implementing the annotations at the backend #252 and [Halil] Decide which page will require annotation and how they will be handled #299.
• We should show the username of the poster of the annotation to let other users know who they are interacting with.
  Acceptance criteria: Users should be able to see username of the annotation poster.
  Example: Post preview in feed shows the username, and it is a good example.
• To make a users to have a better UX, we should only show the delete and edit buttons if the user has created that annotation. If not, there should be no edit or delete buttons available.
  Acceptance criteria: If a user is not the owner of an annotation, he should be shown edit and delete buttons related to that annotation.
  Example: Post deletion in web is a good example.
• In current status, we are not handling the annotation indices well. This should be improved and get into a bug-free status.
  Acceptance criteria: The same logic should be used in both mobile and web apps. It should let users to slice the words, and let multiple annotations to exists in the same page.
  Example: We don't have such structure yet.

[serhan-cakmak]

PRIMARY FEATURES

• Posts shall be filtered by status, Programming Languages, and tags.

  • Acceptance Criteria:
    Some of the filters does not work properly. Filters will be added for language and tags.
  • Example Usage:
    User opens the feed and filters by Python language and sees posts with language python.
    Posts shall be filtered by date interval.

• Posts shall be filtered by date interval.

  • Acceptance Criteria:
    Start Date and End Date parameters will be added to backend service. Date picker layout will be added for date parameters. Posts created within the time interval provided will be filtered.
  • Example Usage:
    User selects start date and end date for the posts she wants to see and views the filtered results.
    Posts shall be sorted by popularity.

• Posts shall be sorted by popularity.

  • Acceptance Criteria:
    New sorting option will be available enabling sorting by the popularity of the filtered posts.
  • Example Usage:
    Users selects sorting method popularity within the list provided and sees the posts in relevant order.

• Posts shall be upvoted from feed.

  • Acceptance Criteria:
    Upvote and downvote buttons should work properly on feed.
  • Example Usage:
    User upvotes a post and sees updated votes.

• Posters' names shall be visible on posts on the feed.

  • Acceptance Criteria:
    Post creator name will be visible on every post on feed

• Comments on posts shall be sorted based on the number of upvotes received.

  • Acceptance Criteria:
    Comments will be ordered according to answer status and upvote count.

• Users shall be able to search for questions within the forum using tags.

  • Acceptance Criteria:
    Search functionality will include a tag-based filter. Users will be able to input multiple tags to refine their search results.
  • Example Usage:
    User enters tags "Python" and "Machine Learning" in the search bar and sees a list of questions tagged with both.

• Users shall be able to search for questions without registering.

  • Acceptance Criteria:
    Search functionality will not require user authentication. Unregistered users can browse the forum using the search bar.
  • Example Usage:
    A guest user types "REST API" in the search bar and sees a list of relevant posts.

• Users shall be able to just discuss on the forum without posting a question.

  • Acceptance Criteria:
    A discussion section will be introduced where users can post open-ended topics without marking them as questions.
  • Example Usage:
    User creates a new discussion thread about "The future of AI in education" and receives comments from other users.

• Users shall be able to list their own comments in their profile.

  • Acceptance Criteria:
  • Users must be able to see all of their bookmarks
  • Example Usage:
  • Users will click the comments button on their profile.

• Users shall be able to list their bookmarked posts in their profile.

  • Acceptance Criteria:
  • Users must be able to see all of their bookmarks
  • Example Usage:
  • Users will click the bookmarks button on their profile.

• Users shall be able to search the other user's profile using search bar..

  • Acceptance Criteria:
  • When a search results in with user profile.
  • Example Usage:
  • User will enter another user's name to search bar, and will see that user's profile as a result.

[damlakayikci]

3- Checklist for API and its documentation

Endpoints that aren't fully implemented yet

• /get_profile
  Endpoints should be improved and should also return bookmarked questions

• /mark_as_unanswered
  Should be implemented just like /mark_as_answered in case the user deletes their answer

Endpoints that aren't present on Swagger page yet

—Profile—

• /user_profile_by_id/int:user_id
• /get_user_profile_by_username/str:username
• /edit_user_profile/int:will_be_edited_user_id
• /delete_user_profile/int:will_be_deleted_user_id
• /upload-profile-pic
• /reset_password
• /reset_password/str:uidb64/str:token
• /interested_languages
• /preferred_languages
• /get_user_profile_by_id/int:user_id

—Question—

• /get_question/int:question_id
• /question/int:question_id/comments
• /mark_as_answered/int:question_id
• /report_question/int:question_id
• /bookmark_question/int:question_id
• /remove_bookmark/int:question_id
• /get_random_reported_question
• /gel_all_questions
• /get_code_snippet_if_empty/int:question_id
• /list_questions_by_time
• /list_questions_by_hotness/int:page_number
• /random_questions
• /upvote_object/str:object_type/int:object_id
• /downvote_object/str:object_type/int:object_id
• /run_code/str:type/int:id
• /code_execute
• /specific_feed/int:user_id
• /question_of_the_day
• /daily_question
• /questions/int:question_id/label-info
• /questions/int:question_id/topic

—Others—

• /home
• /wikipedia
• /search/str:search_strings
• /result/str:wiki_id
• /get_api_languages
• /login
• /signup
• /get_top_five_contributors
• /fetch_feed_at_once/int:user_id
• /multi_search
• /topics

Acceptance Criteria & Example Usage

Acceptance Criteria

The documentation for each endpoint should include the following: the Endpoint URL, HTTP Method, a brief Description of its purpose, required Request Parameters -if necessary- (path, query, or body) with their types and whether they are mandatory, necessary Headers, expected Response (success and error formats). The content should be clear, concise, and consistently formatted to ensure readability and ease of use.

Example Usage

/get_user_profile_by_username/<str:username>

Description:

This endpoint returns all information about a specific user

HTTP Method: GET

Parameters: -

Request Body: -

Response

201: Success

{
"user": {
"username": "damla",
"email": "[email protected]",
"questions": [],
"comments": [],
"bookmarks": [],
"profile_pic": null,
"bio": null,
"interested_topics": [
"Machine Learning"
],
"known_languages": [
"Python (3.11.2)"
],
"name": null,
"surname": null,
"user_id": 24
}
}

400: Error

{
"error": "string"
}

[ceylingebes]

Domain-specific features (e.g. why they're specific, how they're implemented):

• Improvements on syntax highlighting in code execution blocks: In the code execution blocks that users can add in their questions, syntax highlighting is implemented in order to improve readability of the code. It also improves user experience since it provides a familiar environment that programmers usually make developments. The implementation of syntax highlighting was initialized, not finalized, but it should be improved based on the feedback we got from customer. There is syntax highlighting as it is on milestone 2, but not all the keywords or conventionally highlighted elements are highlighted. Also it should be more engaging visually in terms of colors etc. Also if it's possible -it's in the scope of the syntax highlighter API we use- language-specific highlighting should be implemented. If the API we were using to implement syntax highlighting permits to make those changes, these should be implemented as well.

• Acceptance Criteria: There should be language-specific syntax highlighting with more engaging color palette.

• Example Usage:
  

• Improvements on code execution output display: The output of the code snippet that has run by user should be visible right below the aforementioned snippet. Since we are working on a programming language forum, the conventional code running mechanisms and designs should be implemented to gain acceptance by the community. This would improve user experience significantly and needed to be improved based on the feedback we got from customers. In milestone 2, there were bugs that causes to outputs to displayed at the end of the question details page. It should be displayed in a more visually logical place.

• Acceptance Criteria: The output of the code snippet should be displayed at the right under the related code snippet, under the "Run Code" button.

• Example Usage: Code Execution Web Mockup

[mehmeteminipekdal]

Testing Strategies Checklist:

• Tests to be added shall use similar tools used before
  Acceptance criteria: Every written test shall use similar tools stated under "Tools Used" part.
  Example: Tests written in this pr.

Tools Used:

Django Testing Tools:

• django.test.TestCase:
  • Provides database-backed test cases that automatically roll back database changes after each test.
• django.test.Client:
  • Simulates a web client to send HTTP requests (GET, POST, etc.) and verify responses.
• django.core.mail:
  • Used for testing email workflows (e.g., password reset emails). Includes the mail.outbox for capturing sent emails during tests.
• django.utils:
  • timezone:
    • Handles date and time testing in a timezone-aware manner.
  • force_bytes:
    • Converts strings to byte format for encoding purposes, such as generating token-related URLs.
  • urlsafe_base64_encode:
    • Encodes data in a URL-safe format for use in token-based workflows.

Django REST Framework (DRF) Testing Tools:

• rest_framework.test.APIClient:
  • A specialized client for testing DRF-based API endpoints. Supports JWT authentication, custom headers, and JSON payloads.
• rest_framework.status:
  • Provides standard HTTP status codes for making assertions (e.g., status.HTTP_200_OK).

JWT Tools:

• rest_framework_simplejwt.tokens:
  • Provides utilities for creating and validating JWT tokens (RefreshToken, AccessToken) during authentication tests.

Mocking and Patching:

• unittest.mock.patch and MagicMock:
  • Used to mock external services or functions (e.g., token validation, external API calls, or email sending).
  • Ensures tests are isolated from dependencies.

File and Media Testing:

• django.core.files.uploadedfile.SimpleUploadedFile:
  • Used to simulate file uploads (e.g., profile pictures or attachments).
• io.BytesIO:
  • Facilitates in-memory file operations for creating test media files dynamically.

Date and Time Utilities:

• datetime.timedelta:
  • Enables time-based calculations, such as setting token expiration for JWT tests.

Reverse URL Resolution:

• django.urls.reverse:
  • Provides a dynamic way to resolve URLs from their view names and arguments.

Custom Utilities:

• .Utils.utils.run_code:
  • A project-specific utility function, likely used for executing user-submitted code snippets or similar tasks.
• .views.utilization_views.wiki_result and wiki_search:
  • Internal views or utilities that might be tested for their functionality.

[Mutti499]

Few comments to give a brief:

• I am completing the tasks of Serhan and Damla's at this branch and I strongly recommend pulling and merging them to your own branch since most of the backend is changing.
• In Checklist for API and its documentation: Do not use /mark_as_unanswered or /mark_as_answered. It is a bad implementation. Use mark_comment_as_answer and unmark_comment_as_answer.
• in PRIMARY FEATURES: I added an endpoint for returning also comments and annotations but the rest is on the front end. I wrote a big part of the frontend code also to help. Frontend web team, you should check that before that.