Submission: Full Stack Developer Intern Assignment - Sakshya Raghav#40
Open
Rsakshya0930 wants to merge 2 commits into
Open
Submission: Full Stack Developer Intern Assignment - Sakshya Raghav#40Rsakshya0930 wants to merge 2 commits into
Rsakshya0930 wants to merge 2 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Submission Note
What I’d test next if I had more time:
Property-Based Testing: I would implement property-based testing for the dueDate field to ensure the API handles all edge cases of the ISO 8601 format and various time zones.
Security & ID Validation: Currently, the API assumes valid UUIDs. I would add tests to ensure the system handles malformed IDs or SQL/NoSQL injection attempts gracefully.
Race Conditions: Since the data store is in-memory, I'd write stress tests to ensure concurrent requests to PATCH /complete or /assign don't lead to data inconsistency.
Anything that surprised you in the codebase:
Documentation Drift: I was surprised to find that the GET /tasks/stats implementation did not match the documentation. The implementation was missing the total field, which I had to restore and secure with a regression test.
Implicit Status Enums: The validators.js was quite strict about the status being todo, in_progress, or done, yet the README used slightly different terminology in some places. I decided to align everything with the code's internal VALID_STATUSES to ensure consistency.
Questions I’d ask before shipping this to production:
Persistence Strategy: Is there a specific database (SQL vs NoSQL) we plan to migrate to, and should I begin implementing an abstraction layer for the current taskService?
Multi-tenancy/Auth: Will this API need to support multiple users? If so, we need to associate tasks with user IDs and add authentication middleware immediately.