Блог

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

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

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

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

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

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

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

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

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

 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() {
    }
}
  

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

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

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

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

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

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

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

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

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