Cover the parts of the library nothing reached - #2360
Merged
Conversation
Contributor
Coverage Report
File CoverageNo changed files found. |
Coverage went from 72.26% of statements to 79.84%, and from 80.47% of functions to 92.85%. 61 tests, in four new files plus the emitter's. The largest hole was drag and drop. The existing suite calls dropzone.drop() directly, which skips the listeners the constructor binds, so every handler on the element -- the whole point of the library -- ran in no test at all. They are covered now through real DOM events, including the guard that leaves a drag carrying anything other than files alone, and the dropEffect that makes dragging out of Chrome's download bar work. Also covered: paste, the transport failures (ontimeout, onerror and progress forwarding, previously only the success path had tests), displayExistingFile, the fallback form, the removal confirmations, renameFilename, handleFiles and Dropzone.discover. emitter.js reaches 100%. Three of these pin behaviour that is wrong rather than right, each pointing at the roadmap entry that will change it: paste still does not emit addedfiles, displayExistingFile still does not count towards maxFiles (#2003), and constructing with forceFallback returns the fallback element rather than a Dropzone, because fallback() ends in a return and a constructor returning an object overrides this. The emitter's tests sat behind `return describe(...)`, a CoffeeScript conversion artefact that ends the enclosing callback, so anything appended after it was never registered -- which is exactly what happened when the first four tests here were added and silently did not run. The eleven other occurrences in all.js hide nothing today, but they are the same trap, and are removed too. The suite count is unchanged by that, which is the point. The end-to-end suite already drives a real drop through a real DataTransfer against the built bundle, so the gap there was failure: the test server only ever answered 200. It can now reject an upload, and a test drives a real 500 through to the message in the preview.
enyo
force-pushed
the
test-coverage-gaps
branch
from
September 12, 2026 18:06
0f47c4d to
74931ec
Compare
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
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.
Stacked on #2359, which added the measurement. This closes the gaps it exposed.
emitter.jsreaches 100% on all three.The largest hole was drag and drop
The existing suite calls
dropzone.drop()directly, which bypasses the listeners the constructor binds to the element. Every handler —dragstart,dragenter,dragover,dragleave,drop,dragendand the click forwarding, the whole point of the library — ran in no test at all.They are covered now through real DOM events, including the two subtleties:
dropEffectis set tocopyunlesseffectAllowedsays otherwise, which is what makes dragging out of Chrome's download bar work, and the read is wrapped because IE 11 threw on itI checked these have teeth rather than passing vacuously: making
containsFilesalways return true fails four of them.Also covered
paste, the transport failures (ontimeout,onerror, progress forwarding — only the success path had tests),displayExistingFile, the fallback form, the removal confirmations,renameFilename,handleFilesandDropzone.discover.Three tests pin behaviour that is wrong
Each points at the roadmap entry that will change it, so the fix has to be deliberate rather than accidental:
pastedoes not emitaddedfiles, whiledrop()has since 6.2 and the hidden input always hasdisplayExistingFiledoes not count towardsmaxFiles— Fix maxFiles issue when added files from server #2003, where the documented workaround is why it cannot be fixed in a patchnew Dropzone(el, { forceFallback: true })returns the fallback input, not a Dropzone.fallback()ends withreturn this.element.appendChild(...), and a constructor returning an object overridesthisA trap in the test suite itself
The emitter's tests sat behind
return describe(...)— a CoffeeScript conversion artefact. Thereturnends the enclosing callback, so anything appended after it is never registered. That is exactly what happened here: the first four tests I added reported as passing while not running at all, and only counting them caught it.There are eleven more in
all.js. Removing everyreturnthere leaves the count at 252 either way, so none of them hide anything today — but they are the same trap, and they are gone.End-to-end
Better than I expected going in: the suite already drives a real drop through a real
DataTransferagainst the builtdropzone-min.js, so drag-and-drop, the standalone bundle and real HTTP were all covered.The actual gap was failure — the test server only ever answered
200, so no rejected upload could be reached. It can now, and a new spec drives a real500through to the message rendered in the preview. That also pins something worth knowing: because the body isapplication/jsonwith anerrorkey, the user sees the server's own message, notdictResponseError.Still worth adding later, in rough order of value: a chunked upload end to end (the S3 spec covers multipart, not Dropzone's own
chunking), andmaxFilesrejection.What is deliberately still uncovered
dropzone.jssits at 77.42%, and the bulk of the remainder is one block:ExifRestore, roughly a hundred lines of base64 segment manipulation at lines 2026–2179. It is module-private, so testing it means either exporting it — which puts it in the public API for tests alone — or reaching it throughcreateThumbnailwith a real JPEG and canvas.Worth doing, and worth saying where: the roadmap calls #2001, the EXIF rewrite, the highest-risk pull request in the backlog, whose author says they could not test it. That rewrite is exactly when this safety net is needed, so it belongs with it rather than here.
The rest is the jQuery plugin (needs jQuery present at module load),
__guard__/__guardMethod__and the IE 11 branches — all on the 7.0 list for deletion.