在过去的几个月中，我从头开始从事一个很大的项目的后端（REST API）。我们正在遵循BDD（行为驱动开发）标准，因此现在我们进行了大量测试（〜1000）。这些测试是使用Chai编写的-Node.js的BDD框架，但我认为在编写测试时可以将这个问题扩展到一般的良好实践。
起初，我们试图避免尽可能多的代码冗余，并且进行得很好。随着代码和从事该项目的人员的数量的越来越多，它变得越来越混乱，但可读。有时，可以在15分钟内应用的代码的微小变化导致需要更改，例如30多个文件等中的模拟数据和方法，这意味着6个小时的更改和运行测试（极端示例）。
tl：dr
我们现在想重构这些BDD测试。例如，我们具有这样的功能：
function RegisterUserAndGetJWTToken(user_data, next: any){
chai.request(server).post(REGISTER_URL).send(user_data).end((err: any, res: any) => {
token = res.body.token;
next(token);
})
}
在我们的大多数测试文件中都使用了此功能。创建类似test-suite之类的东西是有意义的，它将包含这种功能，或者在编写测试时是否有更好的方法来避免冗余？然后我们可以使用类似的导入：
import {RegisterUserAndGetJWTToken} from "./test-suite";
import {user_data} from "./test-mock-data";
- 您是否有可以分享的好实践？
- 是否有任何可以有用的NPM软件包（或适用的软件包其他编程语言）？
- 您认为这种方法也有弊端（例如会有多个进口）？
- 也许有一种方法可以用于
inject或inherittest-suite每个文件，避免导入并默认在每个文件中？
编辑：忘了提及 - 我的意思是集成测试。
预先感谢！
重构电流测试套件
您的原则应该提高测试本身的抽象水平。这意味着测试应由以域语言表示的高级方法调用组成。例如：
registerUser('John', 'john@smith.com')
lastEmail = getLastEmailSent()
lastEmail.receipient.should.be 'john@smith.com'
lastEmail.contents.should.contain 'Dear John'
现在，在实施这些方法时，可能会发生很多事情。特别是，registerUser函数可以执行发布请求（例如在您的示例中）。getLastEmailSent可以从消息队列或假SMTP服务器中读取。问题是您隐藏了API背后的细节。
如果您遵循此原则，则最终会创建一个自动化层 - 系统面向域的程序化API。创建此层时，您会遵循所有良好的设计原理，例如干燥。
好处是，当发生代码的更改时，在自动化层中而不是在测试本身中只有一个更改测试代码的地方。
我看到您提出的建议（提取RegisterUserAndGetJWTToken和测试数据）是创建自动化层的好一步。我不必担心require的电话。我认为没有任何理由不明确我们的测试所依赖的内容。也许在以后的阶段中，其中一些可以聚集在较大的模块（registration，emailing等）中。
良好的实践可维护测试套件
在正确级别自动化。
有时最好通过UI或休息，但是通常直接调用功能会更明智。例如，如果您编写一项测试以计算发票上的税收，则遍历每个测试箱的整个应用程序将是过度杀伤。最好保留一个端到端测试，看看所有零件是否都会起作用，并在最低水平上自动化所有特定案例。这样，我们获得了良好的覆盖范围，以及测试套件的速度和稳健性。
编写测试时的指导原理是可读性的。
您可以参考此讨论以进行很好的解释。
用与处理生产代码相同的护理处理测试助手代码/自动化层。
这意味着您应该遵循所有好的设计原则，重新谨慎和关注。