我工作的代码库是由不同的团队构建的,他们可以访问不同的专有包。
通常情况下,这是可以的,但是如果我想确保我的代码更改不会破坏它们的构建,我需要像它们一样构建它并运行共享测试。
这里有一个虚拟的例子:
// in SharedComponent.tsx
import { ChildComponent } from 'variations/foo-bar';
const SharedComponent = () => <><ChildComponent /></>;
variations/foo-bar/ChildComponent
的内容根据代码的构建方式而有所不同(本质上,当使用'team-awesome'构建时,variations/foo-bar
被variations-team-awesome/foo-bar
替换,而当使用'team-amazing'构建时,variations-team-amazing/foo-bar
被替换)。
下面是一个例子:
// in variations-team-awesome/foo-bar/ChildComponent.tsx
import { DoThings } from '@proprietary-X/things'
const ChildComponent = () => <div>{DoThings()}</Div>
// in variations-team-amazing/foo-bar/ChildComponent.tsx
import { DoStuff } from '@proprietary-Y/stuff'
const ChildComponent = () => <div>{DoStuff()}</Div>
如果我为我的jest测试构建了SharedComponent
,作为“team-awesome”,但他们的ChildComponent
版本导入了一些我无法访问的专有内容,那么jest将失败,说它找不到模块。
但是,如果ChildComponent
中的导入总是被模拟,那么它就不会作为SharedComponent
的一部分进行测试(假设在这些示例中不模拟它们是有意义的)。
如何有条件地模拟这些导入(即@proprietary-Y/stuff
和@proprietary-X/things
)的不同团队?
1条答案
按热度按时间wz3gfoph1#
原谅比允许容易
在这种情况下,最好尝试导入,只有在失败时才进行mock。
这在测试文件本身中起作用:
注意:当mock用于一个不存在的模块时,需要virtual(这不取决于团队)。
或者使用
__mocks__
文件夹(带有helper函数):这对两个团队来说都应该可以顺利工作,并且当您作为另一个团队进行本地构建并运行共享测试时,只有控制台注销
module '${module}' not found, mocking...
。