Как модульные тесты должны настроить источники данных, если не работающие в сервере приложений?

Некоторая комбинация внедрения зависимостей (будь то через Spring, файлы конфигурации или аргументы программы) и Factory Pattern обычно работают лучше всего.

В качестве примера я передаю аргумент в свои скрипты Ant эти файлы конфигурации установки в зависимости от того, идет ли речь о войне или войне в среде разработки, тестирования или производства.

Все концепция вернулась на передний план. Код более низкого уровня не должен проводить такого рода тестирование. Если вам нужна другая реализация, передайте ее в соответствующем месте.

Возможно, что-то вроде этого (уродливо, но может работать)

 private void isRunningOn( String thatServerName ) { 

     String uniqueClassName = getSpecialClassNameFor( thatServerName );
     try { 
         Class.forName( uniqueClassName );
     } catch ( ClassNotFoudException cnfe ) { 
         return false;
     }
     return true;
 } 

Метод getSpecialClassNameFor вернет класс, уникальный для каждого сервера приложений (и может вернуть новый класс. имена при добавлении дополнительных серверов приложений)

Затем вы используете это как:

  if( isRunningOn("JBoss")) {
         createJBossStrategy....etcetc
  }

 Контекст ctx = new InitialContext ();
Источник данных dataSource = (DataSource) ctx.lookup (jndiName);

Кто конструирует InitialContext? Его конструкция должна находиться вне кода, который вы пытаетесь протестировать, иначе вы не сможете имитировать контекст.

Поскольку вы сказали, что работаете над устаревшим приложением, сначала выполните рефакторинг кода, чтобы вы могли легко внедрить контекст или источник данных в класс. Тогда вам будет проще писать тесты для этого класса.

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

public class Foo {
  private final DataSource dataSource;
  public Foo() { // production code calls this - no changes needed to callers
    Context ctx = new InitialContext();
    this.dataSource = (DataSource) ctx.lookup(jndiName);
  }
  public Foo(DataSource dataSource) { // test code calls this
    this.dataSource = dataSource;
  }
  // methods that use dataSource
}

Но прежде чем вы начнете выполнять этот рефакторинг, у вас должны быть некоторые интеграционные тесты, чтобы прикрыть вашу спину. В противном случае вы не сможете узнать, сломают ли что-нибудь даже простые рефакторинги, такие как перемещение поиска DataSource в конструктор. Затем, когда код станет лучше, станет более тестируемым, вы сможете писать модульные тесты. (По определению, если тест касается файловой системы, сети или базы данных, это не модульный тест - это интеграционный тест.)

Преимущество модульных тестов в том, что они выполняются быстро - сотни или тысячи в секунду - и очень сосредоточены на тестировании только одного поведения за раз. Это позволяет запускать тогда часто (если вы не решаетесь запускать все модульные тесты после изменения одной строки, они выполняются слишком медленно), так что вы получаете быструю обратную связь. И поскольку они очень сфокусированы, вы узнаете, просто взглянув на название неудачного теста, где именно в производственном коде находится ошибка.

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

Есть несколько способов решить эту проблему. Один из них - передать объект Context классу, когда он находится в модульном тесте. Если вы не можете изменить сигнатуру метода, проведите рефакторинг создания исходного контекста до защищенного метода и протестируйте подкласс, который возвращает фиктивный объект контекста, переопределив метод. Это может, по крайней мере, проверить класс, чтобы вы могли оттуда провести рефакторинг до лучших альтернатив.

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

Одна вещь, о которой следует подумать, - как только у вас будет это соединение с базой данных вне контейнера, что вы собираетесь с ним делать? Это проще, но это не совсем модульный тест, если вам нужно нести весь уровень доступа к данным.

Чистый способ сделать это - настроить слушателей жизненного цикла в web.xml . При желании они могут устанавливать глобальные флаги. Например, вы можете определить ServletContextListener в своем web.xml , а в методе contextInitialized установить глобальный флаг, который вы запускаете внутри контейнера. Если глобальный флаг не установлен, значит, вы не работаете внутри контейнера.