That means I have yet another set of documentation to consume, and a whole other dimension of issues I could run into that are not necessarily shared with the regular HTML5 backend I would use for my app. To test this feature, I must also be familiar with how the “testing backend” works, which is something that I don’t have to be familiar with in the first place to build a drag-and-drop functionality using this library.To test this feature, I must be familiar with how this library in particular works internally and its implementation details.In summary, I have a few gripes about their suggested approach: This is tricky, because it can be misleading to unexperienced developers. The linked guide itself admits this, and states that it is the least documented part of the library because of this.ĭoes this mean that I must be competently familiar with how this library in particular works to be able to test it? Well, to me, this is what the documentation is suggesting. So in that last sentence of the previous paragraph, I threw a lot of weird concepts at you: decorated component, backend, testing backend, HTML5 backend… what? These are all internal underlying concepts of react-dnd and dnd-core, all related to how it works under the hood. This will allow you to test it outside of a browser environment, that is, without access to the DOM. Basically you wrap the decorated component using this backend instead of the usual HTML5 backend they provide. There’s a suggestion about using the “test backend”. The feature is done, so how would we go about testing it at this point? If you go to the documentation, you would find a neat “ Testing” section that will probably make your eyes shine. Ok, so let’s say I need to build a table that has drag and droppable rows, looking something like this (by the way, don’t get too distracted by the implementation):Īs you can see, I’m using the classic react-dnd library by the now famous Dan Abramov.
But in reality, the same concepts could be applied to any stack, which is the beauty of it all. I’m using React, and a lot of the snippets and samples are going to be React centric. However, automatically testing these features can be non-trivial, and I’d like to share some of the lessons I’ve learned. Thankfully, though, it has been fairly easy thanks to the rich ecosystem of libraries out there that have already tackled this problem and seem to have it nailed down. To my despair, the app I’m working on at the moment full-time has a lot of drag-and-drop related features all over the place. After spending about a day and a half in testing I am forced to conclude that the HTML5 drag and drop module is not just a disaster, it’s a f*****g disaster. This means that implementing such functionality alone in your app can be quite challenging, and for an unexperienced developer it might be even more challenging to write the proper automated tests for it. This has led many library authors to whip out their own unique approaches to the problem, often very different from each other. This is partly because of just how broken and inconsistent the HTML5 Drag and Drop API is. One of these is drag-and-drop functionality.
However, there are some less common experiences in the Web that are much harder to test. I’m referring to things like clicking buttons, filling out forms, navigating routes… the usual stuff. When it comes to common interactions between a user and a web application, it’s usually pretty straightforward to simulate those actions in a testing environment to assert the correct functionality of an app.
The 100 click and drag how to#
By Ronald Rey How to write better tests for drag-and-drop operations in the browser While keeping it framework-agnostic Photo by Ash Edmonds on Unsplash