我最近想测试一些自定义方法在componentDidMountReact组件的方法中有条件地调用.
componentDidMount() {
if (this.props.initOpen) {
this.methodName();
}
}
我正在使用Jest作为我的测试框架,其中包括jest.fn()模拟/间谍.我已经读过,通过做类似以下的事情,用Sinon测试这将是相当微不足道的:
sinon.spy(Component.prototype, "methodName");
const wrapper = mount(<Component {...props} />);
expect(wrapper.instance().methodName).toHaveBeenCalled();
我正试图用Jest重新创建这个:
Component.prototype.methodName = jest.fn();
const wrapper = mount(<Component {...props} />);
expect(wrapper.instance().methodName).toHaveBeenCalled();
此代码失败并引发以下错误:
jest.fn() value must be a mock function or spy.
Received:
function: [Function bound mockConstructor]
是否可以使用Jest测试此功能？如果是这样,怎么样？
我处理许多在Express服务器上运行的项目,无论它们是前端(即React.js)代码库还是服务器端Node.js codebases.
很多时候,codebases我会根据前端加载条件配置NODE_ENV,例如前端发出请求的restful API的URL.
我多次使用NODE_ENV有条件地加载服务器端Node.js项目的数据库配置等内容.
在一个由开发,登台和生产(3个环境)组成的项目中,我通常会设置我的代码,以根据NODE_ENV被设置为这3个环境中的任何一个(也可能是"本地")来加载配置.
我最近正在开发一个将生产环境称为"实时"的项目.
当我决定为这种环境设置NODE_ENV = live时,同事指出了这种方法的一个主要缺陷.
似乎Express和其他一些Node.js库可以解决这样一个问题:你将使用"生产"或"开发",因为你NODE_ENV的环境使用其他名称会产生意想不到的影响.
例如,Express需要NODE_ENV=production以"生产"模式运行.根据Express文档"测试表明,这样做可以将应用程序性能提高三倍!"
基本上,我很好奇是否通常将NODE_ENV"开发"和"生产"之类的值设置为"我的项目".
我觉得,如果我要将我的代码部署到云上的开发或登台环境,我认为它们不应该以与生产环境不同的Express"模式"运行.
保持配置分开是否更有意义NODE_ENV？
例如,基于类似的变量来构建配置是否有意义APP_ENV,同时确保类似Express的NODE_ENV"开发"或"生产" frameworks/packages.