diff options
Diffstat (limited to 'doc/development/ee_features.md')
-rw-r--r-- | doc/development/ee_features.md | 42 |
1 files changed, 42 insertions, 0 deletions
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 7f74d9660e9..70d7ea7c1a5 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -1079,6 +1079,48 @@ export default { - **EE extra HTML** - For the templates that have extra HTML in EE we should move it into a new component and use the `ee_else_ce` dynamic import +#### Testing modules using EE/CE aliases + +When writing Frontend tests, if the module under test imports other modules with `ee_else_ce/...` and these modules are also needed by the relevant test, then the relevant test **must** import these modules with `ee_else_ce/...`. This avoids unexpected EE or FOSS failures, and helps ensure the EE behaves like CE when it is unlicensed. + +For example: + +```vue +<script> +// ~/foo/component_under_test.vue + +import FriendComponent from 'ee_else_ce/components/friend.vue;' + +export default { + name: 'ComponentUnderTest', + components: { FriendComponent }. +} +</script> + +<template> + <friend-component /> +</template> +``` + +```javascript +// spec/frontend/foo/component_under_test_spec.js + +// ... +// because we referenced the component using ee_else_ce we have to do the same in the spec. +import Friend from 'ee_else_ce/components/friend.vue;' + +describe('ComponentUnderTest', () => { + const findFriend = () => wrapper.find(Friend); + + it('renders friend', () => { + // This would fail in CE if we did `ee/component...` + // and would fail in EE if we did `~/component...` + expect(findFriend().exists()).toBe(true); + }); +}); + +``` + ### Non Vue Files For regular JS files, the approach is similar. |