Testing JDBI

[Aidan McGinley]

I've been following the tutorials and documentation for dropwizard and so far everything has been fine, however when I have tried to add in persistence using JDBI the documentation recommends this approach:

    final DBIFactory factory = new DBIFactory();
    final DBI jdbi = factory.build(environment, configuration.getDataSourceFactory(), "h2");

    final UserDAO userDAO = jdbi.onDemand(UserDAO.class);

Now this seems like it is awfully hard to test.  Is there a better way to add a JDBI DAO in a testable fashion?

[Nasir Rasul]

Hi Aidan,

I'm not entirely sure exactly what you are finding hard to test. It's hard to determine, since you've not included your current approach, or mention what is awful/hard to test. It would be preferably, if you would share some code. Perhaps, dropwizards can share their insights better.

Having said that, I will try to make assumptions, and answer your question. 

If you want to check wether the factories/DBI are properly initialized you probably could write a one off test for that. If you want to test that JDBI is doing things right, your testing scope might be worth reconsideration. JDBI does have a fair amount of tests (https://github.com/jdbi/jdbi/tree/master/src/test/java/org/skife/jdbi/v2). They may give you some inspiration.

If you want to test UserDAO, you can either create UserDAO yourself, or inject it in your test, and test operations as you would test any class. I would treat the tests as if I were testing the queries.

At some point, you have to treat JDBI as a service, and test what makes sense. 

I hope I am able to address your concerns. If not, please clarify a bit further, and I can try and do a better job.

Cheers

Nasir

- Nasir

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aidan McGinley]

Thanks Nasir,

I'm specifically talking about the type of test described here: http://www.dropwizard.io/manual/core.html#testing-applications

That is, testing the application is setup correctly. As soon as you add JDBI in the manner described in the documentation you would have to add an enormous amount of mocking code, you can't simply provide a Datasource stub/dummy. Hopefully that's a bit clearer? Once I'm at a computer I'll post some code

[Aidan McGinley]

See below for example code, as soon as I uncomment line 50 in the application class that is when I run into testing difficulty because the call to build() makes a bunch of calls to the datasource + environment that are passed in, and really I don't want to be mocking all of that, so it just feels like an incorrect recommendation from the dropwizard docs to be doing it in this manner.

My Application Class: http://pastebin.com/JhmQYS0r

My Test Class: http://pastebin.com/EP22j3M7

[Nasir Rasul]

I've posted an example of a test class I use myself.

https://gist.github.com/mnrasul/7859e254ba133f524306

DropwizardAppRule was introduced recently I think. I am not sure exactly when. 

In this example, I am using the runtime configuration to power the tests. There is a way to do a test specific one too. If you google around,

you may stumble on some samples.

Hopefully it helps.

- Nasir

--

[babc...@umich.edu]

You may also find the jdit project useful: https://github.com/arteam/jdit