A lot of the code in src/editors/ uses this sketchy self-import hack to facilitate mocking and avoid circular import errors. It is bad practice and I think it only works because of webpack black magic. All usage of importing from the current file should be removed.
Example of this import * as module from './(self)' pattern:
|
// This 'module' self-import hack enables mocking during tests. |
|
// See src/editors/decisions/0005-internal-editor-testability-decisions.md. The whole approach to how hooks are tested |
|
// should be re-thought and cleaned up to avoid this pattern. |
|
// eslint-disable-next-line import/no-self-import |
|
import * as module from './hooks'; |
As part of this, we should likely create a new ADR that supersedes ADR 0005 for testing - see some of the principles listed in #2075
Personally, I (@bradenmacdonald) try to keep mocking to a minimum and instead of mocking out and overriding hooks, just simulate realistic user interactions with the UI. The only hooks that I recommend mocking out are data loading hooks / mutation hooks, and those are easy enough to mock without these self-import hacks.
A lot of the code in
src/editors/uses this sketchy self-import hack to facilitate mocking and avoid circular import errors. It is bad practice and I think it only works because of webpack black magic. All usage of importing from the current file should be removed.Example of this
import * as module from './(self)'pattern:frontend-app-authoring/src/editors/containers/ProblemEditor/components/EditProblemView/AnswerWidget/hooks.js
Lines 3 to 7 in 99e11d3
As part of this, we should likely create a new ADR that supersedes ADR 0005 for testing - see some of the principles listed in #2075
Personally, I (@bradenmacdonald) try to keep mocking to a minimum and instead of mocking out and overriding hooks, just simulate realistic user interactions with the UI. The only hooks that I recommend mocking out are data loading hooks / mutation hooks, and those are easy enough to mock without these self-import hacks.