Reputation: 685
I'm just wondering, how would I test the JDBC connectivity and form a JUNIT test case! Any idea regarding it please?
Upvotes: 0
Views: 12411
Reputation: 85781
A unit test is not suited to cover the database connectivity. Instead, this is covered by integration tests. Assuming your class handling the JDBC has a method that returns a Connection
, you can write a test for the connection not being null
and isValid
to submit queries and execute them. This is an example using Spring and JUnit1 for this integration test:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({ "/your/resource/package/your-spring-config.xml" })
public class YourJdbcClassTest {
//this will inject an instance of the class that access and manages your JDBC resources
@Autowired
YourJdbcClass yourJdbcClass;
//test the database connection
@Test
public void testGetConnection() throws SQLException {
Connection con = yourJdbcClass.getConnection();
Assert.assertNotNull(con);
Assert.assertTrue(con.isValid(0));
con.close();
}
}
Then, just create tests for your other methods that interacts with JDBC. Just to add, this could be used for code coverage, but if you're using Spring or any other framework that already handles injection of resources (like Connection
), then this kind of test would be useless since it is covered in every integration test case.
1Note that adding Sprint to your JUnit tests would enable you to do integration tests. From the official documentation:
Testing is an integral part of enterprise software development. This chapter focuses on the value-add of the IoC principle to unit testing and on the benefits of the Spring Framework's support for integration testing.
Upvotes: 1
Reputation: 34301
The short answer is don't.
The longer answer is, unless you're running against an actual instance of the database you're going to be using, such tests aren't really testing the system, only an approximation of it and there can be a lot of surprise differences between say Oracle and H2SQL. If you are running against an actual instance of the database, this will slow your test suite down, which usually leads to it not being run as frequently as it should be.
And remember, the tests aren't (shouldn't) just be being run from a developer desktop. They should be run from a CI server, during your release process, etc - all these need their own database instance that's kept up to date with the latest changes. This is doable but more trouble than it's worth.
So, that's why incorporating DB access into Unit Tests is a bad idea, but you still need to test.
Personally, I view tests that interact with the database as Integration tests (written with Condordion or FitNesse) that are run throughout the day against installed instances of my system/database in a known environment. Ideally the database updates should be automatic, as should the installation and start-up of the system.
Upvotes: 1
Reputation: 9872
The problem is I don't think that JDBC connectivity is a matter subject to be unit-tested. JDBC connectivity is environment-dependent, and your unit testing should depend only on your code (and test-related resources). Maybe what you need is to set up integration tests (http://searchsoftwarequality.techtarget.com/definition/integration-testing), and even then I am not sure if it is what you need.
If you need to check JDBC connectivity from your development workstations, beware that everything you put into your unit tests will be executed with your entire test suite (even and specially in your CI environment assuming you have one), so it could pollute your continuous integration and delivery flow if you have one. In the case that you need this to check something in your development workstations, better ask your IT or operations department to check it or include port openings, etc., in their workstation setup procedure.
Upvotes: 1