如何测试Spring配置中的错误?
近年来,我一直致力于使用 Spring MVC 框架用 Java 编写 Web 应用程序。这些项目具有良好的 JUnit 和 JUnit 测试覆盖率。硒。然而,有两次 Spring 配置中的错误通过了测试过程。
在一种情况下,对controllerContext.xml 中的父bean 进行了更改,这也需要对两个继承bean 进行更改。但所需的更改仅对两个继承 bean 之一进行。该错误仅在 Web 应用程序的一小部分但很关键的部分中可见。 Selenium UA 测试后来扩展到直接在 Web 应用程序中检查这一点。在部署之前,但由于错误进入了实时环境,损害已经造成。
在另一种情况下,设置数据格式所需的属性未通过 applicationContext.xml 正确注入。唯一可见的错误是从网络应用程序下载的生成报告的日期格式。很难用 Selenium 进行测试。
使用 Spring MVC 的优点之一是能够在 JUnit 测试中设置注入的对象(即模拟对象),但这并不能告诉您当应用程序实时运行时实际将注入什么环境。
答案可能是集成测试,但是设置和测试可能是一个问题。事实证明,过去运行集成测试很困难……但这是另一个问题……
所以,我非常有兴趣了解人们如何尝试捕获 Spring 配置文件中引入的可能错误。
所以我的问题是:
测试 Spring 配置中的错误的最佳方法是什么?
In recent years I have been working on web applications written in Java using the Spring MVC framework. The projects have good test coverage with JUnit & Selenium. However on two occasions errors in the Spring Configuration have got through the testing process.
In one case a change was made to a parent bean in controllerContext.xml which also required a change to the two inheriting beans. But the required change was only made to one of the two inheriting beans. The error was only visible in a small, but critical, part of the Web application. Selenium UA tests were later extended to check this directly in the Web App. prior to deployment, but the damage had already been done as the error made it into the live environment.
In another case a property required to set the data format was not being injected properly via the applicationContext.xml. The only visible error was in the date format of a generated report downloaded from the web app. Difficult to test with Selenium.
One of the advantages of using Spring MVC is the ability to set the injected objects in your JUnit tests (i.e. a mock object), but this doesn't tell you what you are actually going to get injected when the Application is running in the live environment.
The answer may be integration testing, however setting up & running integration testing has proved to be difficult in the past ... but that's another question ...
So, I'd be really interested in learning how people have tried to catching possible errors introduced into Spring configuration files.
So my question is:
What is the best way to test for errors in the Spring Configuration?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这个测试用例会发挥神奇作用
This test case will do the magic
只有当有人认为/记得测试这些条件时,您描述的错误类型才会被测试捕获:
在这两种情况下,开发人员都进行了更改,但没有验证更改影响的所有地方都没有错误。如何在 JUnit 风格的测试中捕获此类错误,而不依赖于进行更改的人员为他们所犯的错误显式添加测试?换句话说,只有当您记得测试这些类型的错误时,您才能发现它们。
就我个人而言,我认为捕获此类错误的最佳方法是更像 Selenium 的测试,实际调用应用程序并断言正确的行为。
但是,如果您的测试不知道要测试的正确行为,您就无法捕获这样的错误 - 捕获错误需要您首先意识到需要捕获哪些错误。
换句话说,如果测试不知道正确值是什么,就无法测试注入正确值。这些测试不会发现人们认为正确的值实际上是错误的情况。
The type of bugs you describe will only be caught by tests when someone thinks/remembers to test these conditions:
In both cases you have a developer who made a change without verifying that everywhere that change affects does not have errors. How can you catch this type of mistake in a JUnit-style test, without relying on the person making the change to explicitly add a test for the mistake they are making? In other words, you can only catch these types of bugs when you remember to test for them.
Personally I think the best approach for catching mistakes like this is more Selenium-like tests that actually invoke the application and assert the correct behavior.
But if your tests don't know the correct behavior to test, you can't catch mistakes like this - catching the mistakes requires you to first realize what mistakes need to be caught.
In other words - you can't test that the correct values are injected without the test knowing what the correct values are. These tests won't catch scenarios where what someone thinks the correct value is is actually incorrect.
测试类上的
@ContextConfiguration(..)
和@RunWith(SpringJUnit4ClassRunner.class)
这将加载整个上下文。您将需要一个虚拟的
@Test
方法,以便加载上下文。@ContextConfiguration(..)
and@RunWith(SpringJUnit4ClassRunner.class)
on your test classThat will load the entire context. You will need a dummy
@Test
method, so that the context is loaded.