Javascript 单元测试有状态RequireJS模块的模式

假设我有一个RequireJS模块，而我的应用程序中只有一个实例（假设它执行异步操作并向其传递回调）：

//模块/myModule
定义（函数（）{
var模块=函数（）{
var self=这个；
self.runSomething（）{
log（“你好世界”）；
};
};
返回新模块（）；
});

我想对这个模块的一个实例进行单元测试，我发现自己是这样构造这个模块的：

//模块/myModule
定义（函数（）{
返回函数（）{
var self=这个；
self.runRouting（）{
log（“你好世界”）；
};
};
});
//模块/myModuleInstance
定义（[“模块/myModule”]，函数（myModule）{
返回新的myModule（）；
});

这为我提供了一些没有附加状态的东西，我可以从我的单元测试中戳出这些状态，因此在我的单元测试中，我从不引用

modules/myModuleInstance

，只引用

modules/myModule

，每次测试我都会构造它们。然后，应用程序引用

模块/myModuleInstance

这感觉像是一种反模式。我讨厌有额外的“模块实例”部分。我知道单元测试中的setup和teardown方法，并且可以通过这种方式维护实例，但是在目睹了C#在尝试对大量单例进行单元测试时可能发生的情况后，我确实希望避免在单元测试之间摆弄状态，尤其是在使用动态语言时

---

在这种情况下，人们通常做什么？

在Luke McGregor的评论之后，很明显我在第一个代码片段中所做的一切都很好。使用我可以定义一个运行测试的模块，如下所示：

//测试/myModuleTests
定义（[“模块/myModule”]，函数（myModule）{
var instanceOfModule=testr（myModule）；
//运行一些测试
var anotherInstanceOfModule=testr（myModule）；
//运行其他一些测试
});

框架不应该清理测试之间的状态吗？@LukeMcGregor感谢您的评论。原来testr.js一直都在这么做。请看下面我的答案。我只想补充一点，“statefull”RequireJS模块本身可能是一种反模式。RequireJS不应该用来解决应用程序状态的问题，这正是它在这里解决的问题。不受异步需求阻碍的应用程序依赖关系应该使用依赖关系注入来解决——上述方法有可能在维护应用程序状态时混淆采集应用程序资产。