-
Notifications
You must be signed in to change notification settings - Fork 22
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
AN-297-Adding unit tests for Device Registry. #1343
base: staging
Are you sure you want to change the base?
Conversation
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
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.
Thanks @BenjaminSsempala , I have just left some comments for your review. Thanks!
@@ -1,3 +1,4 @@ | |||
require("module-alias/register"); |
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.
What was the motivation for adding the "alias" module to this Models file? Does it help out in the testing process? @BenjaminSsempala
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.
@Baalmart yes, I discovered it was required but I guess because I shifted focus to first finish utils, I'll look more into this as I go into models
Device registry changes in this PR available for preview here |
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.
Thank you @BenjaminSsempala
This is really great work 👏👏👏
I have however just left a few comments that I think could be helpful in refactoring.
Thanks again
let isValid = siteUtil.validateSiteName("134141341"); | ||
assert.equal(isValid, true, "the site name is longer than 4 characters"); | ||
it("should return true if the site name is not longer than 50 characters and shorter than 4 characters", function () { | ||
let isValid = siteUtil.checkStringLength(stubValue.name); |
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.
What is the value of stubValue.name
?
The test definition states that its length is
4 < stubValue.name < 51
However, I can't tell which edge case is being tested here.
Could we test both cases individually in this case for example
Have stubValue.name
with a length less than 4, a value in the acceptable range, and a value greater than 50?
// it("should generate a unique site name given the parish name", function () { | ||
|
||
// const stub = sinon | ||
// .stub(siteModel(stubValue.tenant), "create") | ||
// .returns(stubValue); |
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.
I am a strong proponent of removing unused code rather than just commenting it out. This is because this code will always be available in the git history should you ever need it in the future.
However, this is not a big issue for now so no worries
{ | ||
params: { | ||
locations: [{ lat: stubValue.latitude, lng: stubValue.longitude }], | ||
key: process.env.GOOGLE_MAPS_API_KEY, |
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.
Is it possible to mock the Google maps api response and avoid passing in the actual key.
With this implementation, I can tell we are sending the test requests to google maps which may not be necessary cost wise
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
let match; | ||
while ((match = regex.exec(fileContent))) { | ||
const testName = match[1]; | ||
const testCommand = `mocha ${filePath} --grep "${testName.replace(/"/g, '\\"')}" --exit`; |
Check failure
Code scanning / CodeQL
Incomplete string escaping or encoding
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Device registry changes in this PR available for preview here |
Hi @BenjaminSsempala , is this PR still relevant? |
WHAT DOES THIS PR DO?
STATUS OF CODE COMPLETION
Utils
STATUS OF REVIEW
WHAT ISSUES ARE RELATED TO THIS PR?
HOW DO I TEST OUT THIS PR?
mocha ./utils/test/ut_create-site.js --exit
-You can currently test out the util tests depending on their indicated status of completion above. Simply replace the
ut_create-site.js
in the command below with the targeted test-file for the specific test, for-exampleut_create-device.js
WHICH ENDPOINTS SHOULD BE READY FOR TESTING?:
IS THERE ANY JENKINS CONSOLE LINK FOR CODE COVERAGE AND BUILD INFO?
ARE THERE ANY RELATED PRs?