开发者

junit for REST webservice?

开发者 https://www.devze.com 2023-03-04 01:11 出处:网络
I have a REST(jersey) service exposed which basically delegates the call to DAO to fetch some data from the DB and return it into JSON format, How to unit test the webservice?

I have a REST(jersey) service exposed which basically delegates the call to DAO to fetch some data from the DB and return it into JSON format, How to unit test the webservice? AS i can write jersey client code in junit but what about the data fetch calls that the webservice delega开发者_StackOverflow中文版tes to the dao? The backend code of Logic and DAO can be tested separately but what about the Web Service? So please advice on the best practice.

Thanks! Tarun


If you can provide the DAO with fixture data you can then use REST Assured to test the service easily. Have a look at the usage page for examples.


You could use a mocking library to create mock objects for all your DAO classes. Then you can control what data is returned to your services.


I would say that the choice to deploy a particular bit of functionality is something you make at the last minute. From the point of view of what a service does, it makes no difference whether clients access it using an in-memory call, RMI, HTTP, or anything else.

So I'd advise you to start with a POJO interface for your services. Concentrate on what it does for clients. Test the implementation thoroughly, then wrap it with your deployment layer that takes care of marshalling and unmarshalling data. If you do that, you test your service like any other POJO class.


This would make a good component-test, e.g testing your web-service and it's accompanying persistent store as a 'system-under-test'. You would need to spin up the database as a dependent service. The benefit would be that your test would also cover any liquibase/flyway schema that you define in your service. I don't know what db you are using but there are in-memory databases like h2, embedded Postgres databases, or why not run a docker-image with your specific persistent store (you could let your test automatically start a docker container using docker-java)?

As for testing the web service API itself, I would go for plain JUnit and http-matchers (https://github.com/valid4j/http-matchers).

An example component test would be structured like this:

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

精彩评论

暂无评论...
验证码 换一张
取 消