Adding more tests#92
Conversation
# Conflicts: # package.json
* Deploy to GitHub Pages * Removing jsdoc and docs * Fixes unit tests * Adding browser download to gulpfile * Minor console log tweak * Updating selenium assistant to make gulp download work
* Changing minification for babili * External sourcemap and tidy up of code * Adding license header file * Removing unused dep
* Pulling out minified JS Bundle * Moving to shared build config. Still needs some work * Moving to modular gulp taks and shared build * Removing travis typo * Removing travis TODO
* WIP * Some more updates to match the latest spec * Latest sw-routing updates * Latest sw-runtime-caching updates * Add .min. to output .js file * Broadcast cache update changes * Use .bind() to ensure this is set inside of callback * Syntax tweaks * Demo updates * CacheWrapper => RequestWrapper * CacheWrapper => RequestWrapper * Lint cleanup
JSDoc for the sw-broadcast-cache-update project.
| buildPath: 'build/test/constants.js', | ||
| projectDir: __dirname, | ||
| }), | ||
| buildJSBundle({ |
There was a problem hiding this comment.
Are these all being build so they can used in tests?
There was a problem hiding this comment.
yeah, is thr a better way to do it?
There was a problem hiding this comment.
Ping to @gauntface for best practices around test builds.
|
|
||
| /** | ||
| * set the dbName to store the queue and requests | ||
| * defaults to defaultDBName |
There was a problem hiding this comment.
Would there ever be a need to set the database back to the default name?
There was a problem hiding this comment.
not really, but is used to set the DB name first time
| import {getDbName} from './background-sync-idb-helper'; | ||
|
|
||
| /** | ||
| * Class which maily interacts with outer service worker |
There was a problem hiding this comment.
This doesn't explain what this class does.
There was a problem hiding this comment.
changed, please review
| pushIntoQueue({request}) { | ||
| assert.isInstance({request}, Request); | ||
| this._queue.push({request}); | ||
| return this._queue.push({request}); |
There was a problem hiding this comment.
yep, it returns the underlying promise.
if the dev wants to catch the error or wants to wait upon it
There was a problem hiding this comment.
Could you update the @return {void} JSDoc to reflect that?
| } | ||
|
|
||
| /** | ||
| * takes JSON object and return a Request object to be executed by |
There was a problem hiding this comment.
Couldn't you say "Takes and object" rather than "takes a JSON object".
The input is parsed as JSON or anything.
| * whose maxAge has expired | ||
| * | ||
| * @memberOf Queue | ||
| * @return {void} |
There was a problem hiding this comment.
done, earlier lint was throwing an error
| } | ||
|
|
||
| /** | ||
| * saves the logical queue to DIB |
| 'redirect': 'follow', | ||
| }; | ||
|
|
||
| return queueUtils.getFetchableRequest({idbRequestObject: reqObj}) |
There was a problem hiding this comment.
Whats the difference between get QueueableRequest and getFetchableRequest?
There was a problem hiding this comment.
getQueueableRequest => takes Request and makes it into JSON objec
getFetchableRequest => takes JSON and constructs Request Object
|
Looking through the tests, I can see a few places where the constructor values are checked, but I didn't see any testing of queuing requests and make sure they eventually get made and fail requests get re-attempted - do these tests exist or do they still need writing? |
|
@jeffposnick @gauntface Please suggest how to go about it. |
|
I wouldn't worry about the documentation as part of this PR. (None of the packages are in great shape, honestly, and that's one of the things we were going to look into tomorrow.) I'll take another look at the actual code now! |
| pushIntoQueue({request}) { | ||
| assert.isInstance({request}, Request); | ||
| this._queue.push({request}); | ||
| return this._queue.push({request}); |
There was a problem hiding this comment.
Could you update the @return {void} JSDoc to reflect that?
|
|
||
| let bcmanager; | ||
| /** | ||
| * broadcasts the message with the guven type and url |
| * | ||
| * @param {Object} config | ||
| */ | ||
| function broadcastMessage(broadcastManager, {type, url}) { |
There was a problem hiding this comment.
These parameters look odd. Can you normalize things so that broadcastManager is take in as a named property in a single Object parameter, alongside type and url?
| * @param {String} hash | ||
| * @return {Object} response | ||
| */ | ||
| async function getResponse(hash) { |
There was a problem hiding this comment.
Can you wrap hash in an Object parameter, too? I know it's not as useful when there's only one parameter, but it's more confusing to have some methods take Objects and some take position parameters, and it also makes it easier to add in additional parameters later on.
|
@jeffposnick fixed my documentation. |
|
I didn't have any additional comments about the code that need to be addressed in this PR. Given the scope and history of this PR, I'm fine with merging and addressing follow-ups in smaller chunks. @gauntface, anything you'd like to see resolved before this PR is merged? |
R: @jeffposnick @addyosmani @gauntface
Adding more tests for background sync queue.
Also working on jsDocs