我应该在 Spring 项目中包含系统测试吗？
我的 Spring Web 项目包括：
- util 类；
- 存储库；
- 服务；
- 控制器。
测试如下：
- util 类的单元测试；
- 使用 HSQLDB 进行存储库的 spring 集成测试；
- 使用模拟存储库对服务进行单元测试；
- 使用模拟服务对控制器进行单元测试。
还可能有系统测试来测试整个项目的功能。它可以使用 Selenium 等外部工具来执行，也可以使用 Spring 集成测试来执行。
问题是，我应该在项目中包含这样的 spring 集成系统测试还是应该以某种方式将它们分开？
我发现在项目中包含系统测试有两个问题： 1. 它们需要配置调整，因为此类测试不会使用生产配置运行（例如，测试需要本地数据源，而不是来自 JNDI 的数据源）； 2.它们不是自主的，它们需要一些外部资源等等。我不能像往常一样运行它们单元测试。
您如何组织系统测试？
My Spring web project consists of:
- util classes;
- repositories;
- services;
- controllers.
The tests are as follows:
- unit tests for util classes;
- spring integration tests for repositories with HSQLDB;
- unit tests for services with mock repositories;
- unit tests for controllers with mock services.
There also may be system tests which test the overall project functionality. It can be performed with an external tool like Selenium or it can be performed using Spring integration testing.
The question is, should I include such spring integration system tests in a project or should they be separated somehow?
I see two problems about including system tests in a project:
1. they need configuration tuning because such tests will not run with production config (e.g. tests need a local datasource, not the one from JNDI);
2. they aren't autonomous, they need some external resources and so on. I cannot just run them as usual unit tests.
How do you organize your system testing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在小型项目中，我将它们放在同一个地方。在大型企业项目（例如，您可能会有效利用 Spring 的那种）中，我们通常在单独的包/项目中组织系统测试。这有助于将它们与主代码库分开。
如果您不这样做，就会有各种诱惑重用代码中的类来“帮助”一些应该更加关注系统用户体验的东西（用户可能是另一个系统）。如果发生这种情况，您最终会在项目域类和 UI 之间出现耦合，这将不可避免地导致需要复制大量逻辑，从而帮助它们在实际代码库中保持解耦。
大多数时候，系统场景中的逻辑实际上集中在页面、屏幕、网络调用等上，因此重用主项目中的代码是一种转移注意力的做法。将包分开以避免这种情况发生，因为一旦避免这种情况发生，就不需要将它们放在同一个地方。
但是，请确保将系统测试签入与代码相同的版本控制中。
如果您还没有进行持续集成和测试/部署，那么这可能是另一个领域，一些学习将帮助您处理配置文件。不幸的是，这个问题并不会因为您在单独的项目中进行测试而消失。
On small projects I've kept them in the same place. On large enterprise projects (the kind for which you might usefully leverage Spring, for instance) we've usually organised system tests in a separate package / project. This helps keep them separate from the main codebase.
If you don't do this, there's all kinds of temptation to reuse classes from the code to "help out" in something which should be more strongly focused on the experience of users of the system (a user may be another system). If this happens, you end up with coupling between the project domain classes and the UI, which will have the inevitable effect of needing to duplicate much of the logic which helps keep them decoupled in the real codebase.
Most of the time the logic in system scenarios will actually be focused on pages, screens, web-calls, etc. so reusing code from the main project is a red herring. Keep the packages separate to avoid this happening, and because once you avoid it happening there's no need to have them in the same place.
Do, however, make sure that the system tests are checked in to the same version control as the code.
If you're not doing continuous integration and testing / deployment yet, that might be another area for which some learning will help you with the config files. That problem doesn't go away just because you have tests in a separate project, unfortunately.