джунит для REST webservice? - PullRequest
4 голосов
/ 09 мая 2011

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

Спасибо!Tarun

Ответы [ 4 ]

3 голосов
/ 22 мая 2011

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

1 голос
/ 09 мая 2011

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

0 голосов
/ 03 сентября 2016

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

Что касается тестирования самого 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, ...);
    }
}
0 голосов
/ 09 мая 2011

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

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

...