Link to home
Start Free TrialLog in
Avatar of Steve Sperber
Steve SperberFlag for United States of America

asked on

How to mock Spring's SimpleJdbcInsert when invoked from JUnit to avoid error java.lang.IllegalArgumentException: No DataSource specified

The goal is to attain improvements in java Code Coverage

I am writing JUnit test using Mockito to mock DAO Implementation classes created with Spring's JDBC template  and SimpleJdbcInsert.
Spring src/main/java Class:-

import java.util.HashMap;

import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.simple.SimpleJdbcInsert;

public class SpringClass {
	private SimpleJdbcInsert insertObj;
	private JdbcTemplate template;
	public void setJdbcTemplate(JdbcTemplate template) {
			this.template = template;
			this.insertObj = new SimpleJdbcInsert(template).withTableName("XYZ").usingGeneratedKeyColumns("ID");
		}

	public int insertObjMethod(ParamObj paramObj){
			
			
			
			Map<String, Object> parameters = new HashMap<String, Object>();
			parameters.put("YEAR", paramObj.getYear());
			Number id = insertObj.executeAndReturnKey(parameters);
			return id.intValue();
}

Open in new window



Spring src/test/java Class:-


import org.apache.tomcat.jdbc.pool.DataSource;
import org.junit.Before;
import org.junit.Test;
import org.mockito.Mockito;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.simple.SimpleJdbcInsert;

public class SpringClassTest {
JdbcTemplate template;
	SpringClass dao;
private SimpleJdbcInsert insertObj;
Map<String, Object> parameters = new HashMap<String, Object>();
@Before
	public void setUp() throws Exception {
insertObj= Mockito.mock(SimpleJdbcInsert.class);
parameters.put("YEAR", InsertObj.getYear());
Mockito.doReturn(new Integer(1).intValue()).when(insertObj).executeAndReturnKey(parameters);
}

	@Test ///(expected=java.lang.IllegalArgumentException)
	public void testinsertObjMethod() {
Mockito.doReturn(new Integer(1)).when(insertObj).executeAndReturnKey(Mockito.anyMap());//
		//try{
		dao.SpringClassObject(insertObj);
}

Open in new window


I end up getting error:-
Stack Trace:-
java.lang.IllegalArgumentException: No DataSource specified
	at org.springframework.util.Assert.notNull(Assert.java:112)
	at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:97)
	at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
	at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:280)
	at org.springframework.jdbc.core.metadata.TableMetaDataProviderFactory.createMetaDataProvider(TableMetaDataProviderFactory.java:63)
	at org.springframework.jdbc.core.metadata.TableMetaDataContext.processMetaData(TableMetaDataContext.java:205)
	at org.springframework.jdbc.core.simple.AbstractJdbcInsert.compileInternal(AbstractJdbcInsert.java:276)
	at org.springframework.jdbc.core.simple.AbstractJdbcInsert.compile(AbstractJdbcInsert.java:263)
	at org.springframework.jdbc.core.simple.AbstractJdbcInsert.checkCompiled(AbstractJdbcInsert.java:309)
	at org.springframework.jdbc.core.simple.AbstractJdbcInsert.doExecuteAndReturnKey(AbstractJdbcInsert.java:369)
	at org.springframework.jdbc.core.simple.SimpleJdbcInsert.executeAndReturnKey(SimpleJdbcInsert.java:133)

Open in new window

Avatar of mccarl
mccarl
Flag of Australia image

The answer is that, typically, DAO type classes aren't tested at the "unit test" level, because of the very problem that you have run into. While it may be possible, you will end up writing MORE lines of code in the test than the actual code you are testing which leads to a higher chance of there being bugs in your TEST code that would either just waste your time or worse case, mask a real bug in your code.

This functionality is generally what is tested in "integration tests" (system tests) where you point your DAO code at a real life database, albeit a test version with data based on your test cases, and this verifies correct DAO operation.

The goal is to attain improvements in java Code Coverage
The goal is NOT to have 100% coverage in unit testing, so don't get hung up on this.
Avatar of Steve Sperber

ASKER

Sorry for delay...
Such kind of code is at lot of places and integration test does not cover many such scenario.

The Project is lot more complex and lot of functionality and Integration test.

It is required to have 85% code coverage and this is major bottleneck to achieve to attaining it.
Did you try using Apache Derby or H2?
This question needs an answer!
Become an EE member today
7 DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.