13

I want to test class with make db connection. Class that I want to test accept as param in constructor Connection class. I want to pass mock object to the constructor. Can you tell me good framework with example how to mock db connection?

BenMorel
  • 34,448
  • 50
  • 182
  • 322
nyanev
  • 11,299
  • 6
  • 47
  • 76
  • 1
    You might be interested in this resource: http://programmers.stackexchange.com/questions/118933/what-elements-of-my-junits-should-i-mock – Piotr Nowicki Nov 26 '11 at 23:34

6 Answers6

14

You can use MockRunner, which has support for JDBC. General mocking frameworks like Mockito will also work, but JDBC is a set of interfaces returning each other so hand-mocking will be hard. See for yourself: How to stub/mock JDBC ResultSet to work both with Java 5 and 6?

However mocking JDBC is so brittle and verbose (no matter which tools you use) that I would either suggest abstracting JDBC access within some thin DAO layer (see @duffymo answer) or go for in-memory database like H2.

See also:

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
4

Connection is an interface. Any mocking framework will be able to mock it: EasyMock, Mockito, ...

Mocking it isn't different from mocking any other Java interface.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
4

You can either use a mocking framework such as the ones mentioned in the above answer (I personally use EasyMock) OR Create you own mock object:

class FakeConnection extends Connection{
       // Overrive all method behavious you want to fake.
}
GETah
  • 20,922
  • 7
  • 61
  • 103
3

I wouldn't create a mock connection - it proves nothing, in my opinion.

I can see why you'd mock the repository/DAO itself after you've tested it fully with a live connection. You'd give the mock repository/DAO to a service or other client because you've already tested it - no need to prove that it works until you do an integration test.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • This comment is in 2020.. Lot of big organizations will have something called sonar scan which will expect the code coverage (test cases) and if your project is full of JDBC calls , you have no option other than ending up mocking the jdbc calls. – Stunner Oct 02 '20 at 04:40
  • I know what sonar is. I disagree. You prove nothing by testing a mock. Mocks are meant to be passed to other classes once you’ve proven that the class works. – duffymo Oct 02 '20 at 09:17
  • Agreed. But if you have to satisfy sonar and code coverage and if your organization needs it as a mandatory artifact to have atleast 75% code coverage , what option we are left with other than mocking the calls. It's purely to satisfy sonar code coverage. – Stunner Oct 02 '20 at 11:22
  • Big organizations tend to do things dogmatically, even if they make no sense. I understand your requirement. I'm pointing out that it's not smart. Please carry on satisfying it. You and others should understand that it's worthless. You aren't increasing quality or guaranteeing correctness. – duffymo Oct 02 '20 at 12:50
1

My Acolyte framework is useful for such purposes -> https://github.com/cchantep/acolyte .

With this lib you can create a connection instance for which you provide handler. Implementing handler, you are able to 'dispatch' query or update : producing resultsets or update count (or warning).

cchantep
  • 9,118
  • 3
  • 30
  • 41
1

If you are going to reuse that mock on many test cases you can also consider implementing your own implementation of connection and to reuse that implementation everywhere.

Sebastien Lorber
  • 89,644
  • 67
  • 288
  • 419