Блог

У меня есть открытый сервис REST (джерси), который в основном делегирует вызов DAO для извлечения некоторых данных из базы данных и возврата их в формат JSON, как модульно протестировать веб-сервис? ПОСКОЛЬКУ я могу написать клиентский код jersey в junit, но как насчет вызовов выборки данных, которые веб-сервис делегирует dao? Внутренний код Logic и DAO можно протестировать отдельно, но как насчет веб-сервиса? Поэтому, пожалуйста, посоветуйте наилучшую практику.

Спасибо! Tarun

Если вы можете предоставить DAO данные о параметрах, вы можете затем использовать REST Assured для простого тестирования сервиса. Взгляните на страницу использования для примеров.

Вы могли бы использовать библиотеку макетов для создания макетных объектов для всех ваших классов DAO. Затем вы можете контролировать, какие данные возвращаются в ваши сервисы.

Я бы сказал, что выбор в пользу развертывания определенной части функциональности — это то, что вы делаете в последнюю минуту. С точки зрения того, что делает сервис, не имеет значения, обращаются ли к нему клиенты с помощью вызова в памяти, RMI, HTTP или чего-либо еще.

Итак, я бы посоветовал вам начать с интерфейса POJO для ваших сервисов. Сконцентрируйтесь на том, что он делает для клиентов. Тщательно протестируйте реализацию, затем оберните ее своим уровнем развертывания, который заботится о сортировке и отмене сортировки данных. Если вы это сделаете, вы протестируете свой сервис как любой другой класс POJO.

Это было бы хорошим тестированием компонентов, например, для тестирования вашего веб-сервиса и сопровождающего его постоянного хранилища как «тестируемой системы». Вам нужно было бы развернуть базу данных как зависимую службу. Преимуществом было бы то, что ваш тест также охватывал бы любую схему liquibase / flyway, которую вы определяете в своем сервисе. Я не знаю, какую базу данных вы используете, но есть базы данных в памяти, такие как h2, встроенные базы данных Postgres, или почему бы не запустить docker-image с вашим конкретным постоянным хранилищем (вы могли бы позволить вашему тесту автоматически запускать контейнер docker с использованием docker-java)?

Что касается тестирования самого API веб-сервиса, я бы выбрал простой JUnit и http-matchers (https://github.com/valid4j/http-matchers).

Пример тестирования компонента был бы структурирован следующим образом:

 public class MyWebServiceTest {
    private static final DatabaseRule DB = new MyDatabaseRule();
    private static final DropwizardAppRule<AppConfig> APP = new DropwizardAppRule<>(App.class, 
        resourceFilePath("config.yml"), config("db.url", DB.url()));

    @ClassRule
    public static final RuleChain RULE = RuleChain.outerRule(DB).around(APP);

    private final Client client = ClientBuilder.newClient();

    @Test
    public void exampleTest() {
        Response r = client.target("http://localhost:" APP.getLocalPort() "/path").request().post(...);

        assertThat(response, hasStatus(OK));
        assertThat(response, ...);
    }
}