Я хотел бы использовать ограниченные по объему бобы запроса в своем приложении. Я использую JUnit4 для тестирования. Если я пытаюсь создать один в тесте как это:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:spring/TestScopedBeans-context.xml" })
public class TestScopedBeans {
protected final static Logger logger = Logger
.getLogger(TestScopedBeans.class);
@Resource
private Object tObj;
@Test
public void testBean() {
logger.debug(tObj);
}
@Test
public void testBean2() {
logger.debug(tObj);
}
Со следующим бобовым определением:
И я добираюсь:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'gov.nasa.arc.cx.sor.query.TestScopedBeans': Injection of resource fields failed; nested exception is java.lang.IllegalStateException: No Scope registered for scope 'request'
<...SNIP...>
Caused by: java.lang.IllegalStateException: No Scope registered for scope 'request'
Таким образом, я нашел этот блог, который казался полезным: http://www.javathinking.com/2009/06/no-scope-registered-for-scope-request_5.html
Но я заметил, что он использует AbstractDependencyInjectionSpringContextTests, который, кажется, удерживается от использования в Spring 3.0. Я использую Spring 2.5 в это время, но думал, что не должно быть слишком трудно переключить этот метод для использования AbstractJUnit4SpringContextTests, как документы предполагают (хорошо, документы связываются с 3,8 версиями, но я использую 4.4). Таким образом, я изменяю тест для расширения AbstractJUnit4SpringContextTests... то же сообщение. Та же проблема. И теперь prepareTestInstance () метод, который я хочу переопределить, не определяется. Хорошо, возможно, я помещу те вызовы registerScope где-то в другом месте... Таким образом, я читал больше о TestExecutionListeners и думаю, что это было бы лучше, так как я не хочу должным быть наследовать пружинную структуру пакета. Таким образом, я изменил свой Тест на:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:spring/TestScopedBeans-context.xml" })
@TestExecutionListeners({})
public class TestScopedBeans {
ожидание я должен был бы создать пользовательского слушателя, но я, когда я выполнил его.Работает! Большой, но почему? Я не вижу, где какой-либо из слушателей запаса регистрирует объем запроса или объем сессии, и почему был бы они? нет ничего, чтобы сказать, что я хочу это все же, это не мог бы быть Тест для Spring код MVC...
Тест пройден, потому что он ничего не делает :)
Когда вы опускаете аннотацию @TestExecutionListeners
, Spring регистрирует 3 слушателя по умолчанию, включая один, называемый DependencyInjectionTestExecutionListener
. Это слушатель, отвечающий за сканирование вашего тестового класса в поисках объектов для внедрения, включая аннотации @Resource
. Этот слушатель попытался внедрить tObj
и потерпел неудачу из-за неопределенной области видимости.
Когда вы объявляете @TestExecutionListeners ({})
, вы подавляете регистрацию DependencyInjectionTestExecutionListener
, и поэтому тест никогда не получает внедренного tObj
, и поскольку ваш тест не проверяет существование tObj
, он проходит.
Измените свой тест так, чтобы он выполнял следующее, и он завершился ошибкой:
@Test
public void testBean() {
assertNotNull("tObj is null", tObj);
}
Итак, с вашими пустыми @TestExecutionListeners
тест пройден, потому что ничего не происходит .
Теперь перейдем к вашей исходной задаче.Если вы хотите попробовать зарегистрировать область запроса в тестовом контексте, посмотрите исходный код для WebApplicationContextUtils.registerWebApplicationScopes ()
, вы найдете строку:
beanFactory.registerScope(WebApplicationContext.SCOPE_REQUEST, new RequestScope());
Вы можете попробовать это, и посмотрите, как у вас дела, но могут быть странные побочные эффекты, потому что вы на самом деле не предназначены для этого в тесте.
Вместо этого я бы порекомендовал перефразировать ваш тест, чтобы вам не потребовались bean-компоненты с ограниченным объемом запросов. Это не должно быть трудным, если вы пишете автономные тесты, жизненный цикл @Test
не должен быть длиннее, чем жизненный цикл bean-компонента с областью действия запроса. Помните, нет необходимости тестировать механизм области видимости, он является частью Spring, и вы можете предположить, что он работает.