-
Notifications
You must be signed in to change notification settings - Fork 0
Testing
The test suite is divided into broad categories of tests including: 测试套件分为以下几大类测试：
- Unit tests | 单元测试
- Integration tests | 集成测试
- Acceptance tests | 验收测试
- Performance tests | 性能测试
- Memory leak tests | 内存泄漏测试
The performance tests exist to aid development of performance-critical components. 性能测试的存在是为了帮助开发性能关键型组件。
Tests can be run using Pytest. 可以使用 Pytest 运行测试。
If you’re using PyCharm then tests should run directly by right clicking on the respective folder (or top-level tests folder) and clicking ‘Run pytest’. 如果您使用的是 PyCharm，则应该通过右键单击相应的文件夹（或顶级测试文件夹）并单击“运行 pytest”直接运行测试。
Alternatively you can use the pytest command from the root level tests directory, or the other subdirectories. 或者，您可以从根级别的测试目录或其他子目录使用 pytest 命令。
Unit tests will often include other components acting as mocks. The intent of this is to simplify the test suite to avoid extensive use of a mocking framework, although MagicMock objects are currently used in particular cases. 单元测试通常会包含其他充当模拟的组件。这样做的目的是简化测试套件，避免过度使用模拟框架，尽管 MagicMock 对象目前在特定情况下使用。
Code coverage output is generated using coverage and reported using codecov. 代码覆盖率输出使用 coverage 生成，并使用 codecov 报告。
High test coverage is a goal for the project however not at the expense of appropriate error handling, or causing “test induced damage” to the architecture. 高测试覆盖率是该项目的目标，但不能以牺牲适当的错误处理或对架构造成“测试诱导的损害”为代价。
There are currently areas of the codebase which are impossible to test unless there is a change to the production code. For example the last condition check of an if-else block which would catch an unrecognized value, these should be left in place in case there is a change to the production code - which these checks could then catch. 目前，代码库中有一些区域是无法测试的，除非对生产代码进行更改。例如，if-else 块的最后一个条件检查，它会捕获未识别的值，这些检查应该保留，以防对生产代码进行更改 - 这些检查可以捕获这些更改。
Other design-time exceptions may also be impossible to test for, and so 100% test coverage is not the ultimate goal. 其他设计时异常也可能无法测试，因此 100% 的测试覆盖率不是最终目标。
The pragma: no cover comments found throughout the codebase exclude code from test coverage. The reason for their use is to reduce redundant/needless tests just to keep coverage high, such as: 在整个代码库中找到的 pragma: no cover 注释将代码从测试覆盖率中排除。使用它们的原因是为了减少冗余/不必要的测试，只是为了保持高覆盖率，例如：
- Asserting an abstract method raises NotImplementedError when called. 断言抽象方法在调用时引发 NotImplementedError。
- Asserting the final condition check of an if-else block when impossible to test (as above). 在无法测试时断言 if-else 块的最终条件检查（如上所述）。
These tests are expensive to maintain (as they must be kept in line with any refactorings), and offer little to no benefit in return. The intention is for all abstract method implementations to be fully covered by tests. Therefore pragma: no cover should be judiciously removed when no longer appropriate, and its use restricted to the above cases. 这些测试的维护成本很高（因为它们必须与任何重构保持一致），并且几乎没有任何好处。我们的目的是对所有抽象方法的实现进行全面测试。因此，当不再适用时，应谨慎地删除 pragma: no cover，并将其使用限制在上述情况下。