Feature Overview
...
Studio interface (drag_and_drop_edit.js) contains single function/class DragAndDropEditBlock(runtime, element, params) that follows JS XBlock signature.
...
- DnDv2 test suite heavily relies on integration tests - might be good to replace at least some of those with unit tests (python and JS)
- Take very long time to run entire suite
- No JS unit tests
- JS code coverage is never collected (there are tools for instrumenting selenium to do so, but no one actually investigated this).
- Some tests are fragile (but not flaky) - under certain conditions element to receive a click is not visible in the selenium viewport, which results in an error. All of such tests have `scroll_down` parameter somewhere in the call chain - adjusting the value might be needed when DnDv2 layout changes.
- Code coverage result is probably an over-estimation as integration tests tend to hit a lot of lines, while actually testing a few. Branch coverage might be quite poor.
- Complete lack of logging
- No load tests, but most likely there shouldn't be any problem.
- Trivial tech debt:
- 2 handlers do not use XBlock.json_handler decorator, but still return "application/json"
- Keeping highest available grade is not documented in any student-facing part of the system, so students only can discover it by trial and error; also, this is not in line with CAPA problems
- Significant vertical separation - methods in DragAndDropBlock are not always semantically grouped together.
- Very long and complicated methods (i.e. get_feedback)
- DragAndDropBlock class resembles a God Object a bit - might make sense to start pulling it apart (this is considered and certain options are evaluated now)
- Some methods and properties have to be invoked in certain order (and that order is not explicitly visible) - potential source of bugs (examples: one, two):
- Complex frontend code + different libs are used for editor and for student view (VirtualDom vs Handlebars).
- (Arguable) Student view does not use templates at all - as a result everything is constructed via VirtualDom calls - complex and non-intuitive (~500 lines of code building DOM elements)
...