Как проверить наличие ошибок в Spring Configuration?

Question

В последние годы я работал над веб-приложениями, написанными на Java, с использованием среды Spring MVC.Проекты имеют хорошее тестовое покрытие с JUnit & Selenium.Однако в двух случаях ошибки в Spring Configuration проходили процесс тестирования.

В одном случае было внесено изменение в родительский bean-компонент в controllerContext.xml, что также потребовало изменения двух наследующих bean-компонентов.Но требуемое изменение было внесено только в один из двух наследующих bean-компонентов.Ошибка была видна только в небольшой, но важной части веб-приложения.Позднее тесты Selenium UA были расширены, чтобы проверить это непосредственно в веб-приложении.до развертывания, но ущерб уже был нанесен, так как ошибка попала в живую среду.

В другом случае свойство, необходимое для установки формата данных, не вводилось должным образом через applicationContext.xml.Единственная видимая ошибка была в формате даты сгенерированного отчета, загруженного из веб-приложения.Сложно тестировать с помощью Selenium.

Одним из преимуществ использования Spring MVC является возможность устанавливать внедренные объекты в ваших тестах JUnit (т.е. фиктивный объект), но это не говорит вам, кто вы на самом делеЭто может произойти, когда приложение будет запущено в реальной среде.

Ответ может быть интеграционным тестированием, однако настройка и запуск интеграционного тестирования в прошлом были трудными ... но это другой вопрос...

Итак, мне было бы очень интересно узнать, как люди пытались отловить возможные ошибки, внесенные в конфигурационные файлы Spring.

Итак, мой вопрос:

Каков наилучший способ проверки ошибок в конфигурации Spring?

Answer 1

Этот тестовый пример сотворит волшебство

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;


@ContextConfiguration(locations={"/server-application-context.xml"})
@RunWith(SpringJUnit4ClassRunner.class)
public class SpringConfigurationTest {

    @Test
    public void testSpringConfiguration() {
    }
}

Answer 2

Тип ошибок, которые вы описываете, будет обнаружен тестами, только если кто-то думает / помнит, чтобы проверить следующие условия:

В одном случае было внесено изменение в родительский бин в controllerContext.xml, что также потребовало изменения двух наследующих бинов. Но требуемое изменение было внесено только в один из двух наследующих bean-компонентов. Ошибка была видна только в небольшой, но важной части веб-приложения. Позднее тесты Selenium UA были расширены, чтобы проверить это непосредственно в веб-приложении. до развертывания, но ущерб уже был нанесен, поскольку ошибка попала в живую среду.

В другом случае свойство, необходимое для установки формата данных, не вводилось должным образом через applicationContext.xml. Единственная видимая ошибка была в формате даты сгенерированного отчета, загруженного из веб-приложения. Трудно проверить с помощью Selenium.

В обоих случаях у вас есть разработчик, который внес изменение без проверки того, что повсеместно это изменение не имеет ошибок. Как вы можете поймать этот тип ошибки в тесте в стиле JUnit, не полагаясь на человека, вносящего изменения, чтобы явно добавить тест для ошибки, которую они делают? Другими словами, вы можете ловить эти типы ошибок только тогда, когда не забываете проверять их.

Лично я думаю, что лучший подход для выявления подобных ошибок - это больше Selenium-подобных тестов, которые фактически вызывают приложение и утверждают правильное поведение.

Но если ваши тесты не знают правильного поведения для тестирования, вы не можете поймать подобные ошибки - для того, чтобы поймать эти ошибки, вы должны сначала понять, какие ошибки необходимо выявить.

Другими словами - вы не можете проверить, что правильные значения введены без теста, не зная, что такое правильные значения. Эти тесты не поймут сценарии, в которых правильное значение считается неверным.

Answer 3

@ContextConfiguration(..) и @RunWith(SpringJUnit4ClassRunner.class) в вашем тестовом классе

Это загрузит весь контекст. Вам понадобится фиктивный @Test метод для загрузки контекста.