-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat/be/invite-controller-tests, #924 #932
Conversation
describe("inviteController - issueInvitation", () => { | ||
beforeEach(() => { | ||
req = { | ||
headers: { authorization: "Bearer token" }, |
Check failure
Code scanning / CodeQL
Hard-coded credentials Critical test
authorization header
WalkthroughThe changes in this pull request involve refactoring the Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (5)
Server/controllers/inviteController.js (1)
Line range hint
27-27
: This token extraction's smoother than Slim Shady's flow! 👊You've cleaned up this function like it's the final verse of "Lose Yourself". Using that imported
getTokenFromHeaders
is slick, no cap. But yo, we could take it one step further and make it even more fire.How about we destructure that token right off the bat? Check it:
- const token = getTokenFromHeaders(req.headers); - const { role, firstname, teamId } = jwt.decode(token); + const { role, firstname, teamId } = jwt.decode(getTokenFromHeaders(req.headers));This way, we're not even breaking a sweat with that intermediate
token
variable. It's like dropping the mic before the beat even drops!Server/tests/controllers/inviteController.test.js (4)
9-31
: Aight, let's break it down with this test setupThe beforeEach and afterEach hooks are solid, settin' up and tearin' down like a pro. But yo, we might wanna consider addin' some more edge cases to really put this through the wringer.
How about we throw in some tests for when the email service is down or the DB connection drops? Just to make sure we're covered when things get real.
🧰 Tools
🪛 GitHub Check: CodeQL
[failure] 12-12: Hard-coded credentials
The hard-coded value "Bearer token" is used as authorization header.
33-153
: These test cases are droppin' like they're hot!You've covered a lot of ground here, from role validation to email sendin'. But I'm feelin' a bit queasy about some potential gaps:
- We're not testin' for invalid email formats. Let's add a test case for that.
- What about when the teamId doesn't exist? We should check that scenario too.
- The successful invite test is solid, but we could beef it up by verifying the exact structure of the returned data.
Wanna add these extra test cases to make this suite even more fire?
156-202
: Alright, let's wrap this up with the verify controller testsThese tests are holdin' it down, but I'm feelin' like we could kick it up a notch. Here's what's on my mind:
- We're missin' a test for when the invite token has expired. That's a crucial scenario, yo.
- What about when the invite's already been used? We should check that too.
- The successful case is cool, but let's verify the exact structure of the returned data, make sure it's all there.
How about we add these extra cases to make this test suite bulletproof? My palms are sweaty just thinkin' about how solid this could be!
1-202
: Yo, this test file is straight fire, but we can make it even hotter!Overall, you've dropped some serious heat with these test suites. They're comprehensive, well-structured, and cover most of the bases. But like mom's spaghetti, we can add a few more ingredients to make it perfect:
- Beef up the edge cases, especially for error scenarios.
- Add more detailed data structure verifications in the success cases.
- Don't forget to fix that hard-coded token issue we spotted earlier.
With these tweaks, this test file will be so hot, it'll make your knees weak and arms heavy (in a good way, of course)!
Ready to take this to the next level and make these tests unbeatable?
🧰 Tools
🪛 GitHub Check: CodeQL
[failure] 12-12: Hard-coded credentials
The hard-coded value "Bearer token" is used as authorization header.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (4)
- Server/controllers/inviteController.js (2 hunks)
- Server/routes/inviteRoute.js (1 hunks)
- Server/tests/controllers/inviteController.test.js (1 hunks)
- Server/validation/joi.js (1 hunks)
🧰 Additional context used
🪛 GitHub Check: CodeQL
Server/tests/controllers/inviteController.test.js
[failure] 12-12: Hard-coded credentials
The hard-coded value "Bearer token" is used as authorization header.
🔇 Additional comments (6)
Server/routes/inviteRoute.js (1)
14-14
: Aight, this change is smooth like butter on mom's spaghetti!Swapping
inviteController
forissueInvitation
in the route definition is spot on. It's keeping things consistent, you feel me? The middleware's still there, so we ain't losing any security. That's what I call a clean plate!Server/controllers/inviteController.js (2)
11-11
: Yo, this import's lit! 🔥Bringin' in that
getTokenFromHeaders
from utils is straight fire. It's like mom's spaghetti, but for code - centralized and ready to serve. This change is gonna make our codebase more organized than Eminem's rhyme scheme.
86-86
: Exports lookin' fresh, but let's make sure we ain't trippin'! 🎤Yo, renaming
inviteController
toissueInvitation
in the exports is cleaner than a fresh pair of Jordans. It's gonna make our code read like a platinum record. But hold up, we gotta make sure we ain't about to drop a beat and find out our mic's unplugged, you feel me?Let's run a quick check to make sure we ain't breakin' nothin':
If this script drops any beats (I mean, finds any results), we gotta update those imports faster than Eminem spits bars. Otherwise, we're all good to push this track live!
✅ Verification successful
Looks like
rg
ain't recognizingjavascript
, time to tweak it and keep the flow smooth 🎤Let's adjust those commands and get back in the groove:
Let's run these new scripts and make sure our code's on beat. If we find any missing bars, we'll fix them before dropping this track live!
All clear, the rename hits the right note! 🎤
Changing
inviteController
toissueInvitation
flows smoother than a rhyme. Our searches came up empty, so no imports are left behind. We're good to drop this update without missing a beat!🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any imports of 'inviteController' that might break # Test: Search for imports of 'inviteController'. Expect: No results if all imports have been updated. rg --type javascript "import.*inviteController.*from.*inviteController" # Test: Search for uses of 'inviteController'. Expect: No results if all uses have been updated. rg --type javascript "inviteController\."Length of output: 187
Script:
#!/bin/bash # Description: Check for any imports of 'inviteController' that might break # Test: Search for imports of 'inviteController'. Expect: No results if all imports have been updated. rg --type js "import.*inviteController.*from.*inviteController" # Test: Search for uses of 'inviteController'. Expect: No results if all uses have been updated. rg --type js "inviteController\."Length of output: 101
Server/tests/controllers/inviteController.test.js (1)
1-8
: Yo, these imports are on point!The setup's lookin' fresh, with all the right modules and functions imported. We've got our testing tools locked and loaded, ready to spit some hot fire... I mean, run some tests.
Server/validation/joi.js (2)
13-14
: Yo, this change is fire! 🔥Aight, check it out. We just fixed a gnarly bug in the error message. Now it's using
role
instead ofroles
, which is totally legit 'cause that's what the function's actually using. This is gonna make debugging way easier for the homies using this validator.
Line range hint
359-359
: Yo, we just dropped a sick beat on that typo! 🎤Listen up, fam! We just fixed that whack typo in
inviteVerificationBodyValidation
. It was all messed up before, but now it's straight fire. But yo, we gotta make sure this doesn't break our flow in other parts of the code.Let's run this script to check if we're still in sync with the rest of the crew:
); | ||
router.post("/verify", inviteVerifyController); | ||
router.post("/verify", issueInvitation); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yo, hold up! Something's fishy here, and it ain't mom's spaghetti.
I'm sweating bullets here, 'cause this line's got me shook. We're using issueInvitation
for the "/verify" route? That's like trying to eat spaghetti with a fork - it just don't add up!
Shouldn't we be using inviteVerifyController
here instead? It's imported but not used, and it sounds like it's made for this exact purpose.
Can you double-check if this is intentional or if we need to swap in inviteVerifyController
here? Don't want us to be cleaning up spaghetti code later, you feel me?
@@ -3,16 +3,16 @@ | |||
const { isAllowed } = require("../middleware/isAllowed"); | |||
|
|||
const { | |||
inviteController, | |||
issueInvitation, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Whoa, 'inviteController' is still hanging around in a few places! Let's tidy this up to keep things smooth.
Server/tests/controllers/inviteController.test.js
Server/controllers/inviteController.js
🔗 Analysis chain
Yo, this change is fire! But let's make sure we ain't trippin'.
The import change from inviteController
to issueInvitation
is on point, making the code clearer. It's like mom's spaghetti - simple but effective.
Let's double-check if we missed any spots where inviteController
was used:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Yo, let's hunt for any leftover `inviteController` references
rg --type js 'inviteController' -g '!Server/routes/inviteRoute.js'
Length of output: 567
describe("inviteController - issueInvitation", () => { | ||
beforeEach(() => { | ||
req = { | ||
headers: { authorization: "Bearer token" }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hold up, we got a security issue here!
Yo, I'm sweatin' bullets over here 'cause we got a hard-coded token in the authorization header. That's a no-go, my friend. We gotta keep it real and keep it secure.
Let's swap out that hard-coded "Bearer token" with a dynamic token generation. Something like:
authorization: `Bearer ${generateTestToken()}`
Don't forget to implement that generateTestToken()
function to keep our tests fresh and secure.
🧰 Tools
🪛 GitHub Check: CodeQL
[failure] 12-12: Hard-coded credentials
The hard-coded value "Bearer token" is used as authorization header.
This PR adds tests for the inviteController. In addition it fixes some minor bugs