tiagobento commented on issue #874: URL: https://github.com/apache/incubator-kie-issues/issues/874#issuecomment-1921599875
@jomarko Hi! Looking good so far. A few comments from my end: 1. I like how you defined "Goals" and "Non-goals" in the description here, it's important to know where we draw to line and stop bending and twisting to test something that should really be somewhere else. One thing I'll add to the sections you created, is that I think we would benefit a lot from separating functional from non-functional requirements. Let me explain it better. Testing whether or not a node can be correctly dragged from the Palette to the Diagram is very close to testing whether or not the copy/paste mechanism works, but testing that nodes components are not unnecessarily re-rendered when editing the Diagram, is not. We have a lot of "unsaid" non-functional requirements for the new DMN Editor, and I think it would be great if we could map them as part of the test suite too. WDYT? 2. Integration with External models is really complicated and needs to be thoroughly tested, and although I understand where you're coming from with saying that these tests belong on KIE Sandbox / VS Code extensions, and even agree that there should be some sort of testing for this features on their test suites, I think the DMN Editor test suite should have a lot more tests covering External models. Right now, the entire API of the DMN Editor is defined by the Props of the DmnEditor component, which include some properties related to External model integration. I.e., `onRequestExternalModelByPath`, `onRequestExternalModelsAvailableToInclude`, `externalModelsByNamespace`. The last one, `externalModelsByNamespace`, really is where the DmnEditor component gets everything it needs from External models, and there are so so many things to test, that I think we should "mock" multi-file workspaces and test them as part of the DMN Editor suite. Note that for KIE Sandbox and VS Code Extensions, we'll also have `dmn-editor-envelope` at play, and it has some logic related to multi-tab editing etc, that's what's really not in scope for the DMN Editor suite, IMHO. 3. Although I agree that we'll need **some** DMN files to be versioned and opened in the DMN Editor, I think we should try and aim for creating the majority of our fixtures during the tests themselves. WDYT? 4. The "Creating custom DMN types from the java files" feature is not present on the new DMN Editor yet. See https://github.com/apache/incubator-kie-issues/issues/782 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
