Spring DA aide à écrire des DAO. Lorsque vous utilisez iBATIS comme framework de persistance et que vous étendez SqlMapClientDaoSupport, un mock SqlMapClient doit être défini pour le DAO, mais je ne peux pas le faire. SqlMapClientTemplate n'est pas une interface et EasyMock ne peut pas créer un simulacre pour cela.Comment tester unitairement un DAO qui étend SqlMapClientDaoSupport
Les tests DAO et unitaires ne s'entendent pas bien! Cela n'a aucun sens de se moquer de quoi que ce soit dans un composant qui ne contient aucune logique métier et se concentre sur l'accès à la base de données. Vous devriez plutôt essayer d'écrire un test d'intégration. Reportez-vous à la documentation de référence du ressort, chapitre 8.3: http://static.springframework.org/spring/docs/2.5.x/reference/testing.html
Essayez Mockito. Il permet de fausser les classes, pas seulement les interfaces.
Cette raison exacte est pourquoi je ne vais pas de SqlMapClientDaoSupport. Au lieu de cela, j'injecter une dépendance au SqlMapClientTemplate (tapé comme l'interface SqlMapClientOperations). Voici un exemple de Spring 2.5:
@Component
public class MyDaoImpl implements MyDao {
@Autowired
public SqlMapClientOperations template;
public void myDaoMethod(BigInteger id) {
int rowcount = template.update("ibatisOperationName", id);
}
}
Et une autre raison pour laquelle la composition est meilleure que l'héritage. –
Comme suggéré @Banengusk - cela peut être réalisé avec Mockito. Cependant, il est important d'établir que votre DAO utilisera un Spring SqlMapClientTemplate qui enveloppe votre maquette SqlMapClient. Enfait, SqlMapClientTemplate délègue des invocations au SqlMapSession dans la couche IBatis.
donc une configuration simulée supplémentaire est nécessaire:
mockSqlMapSession = mock(SqlMapSession.class);
mockDataSource = mock(DataSource.class);
mockSqlMapClient = mock(SqlMapClient.class);
when(mockSqlMapClient.openSession()).thenReturn(mockSqlMapSession);
when(mockSqlMapClient.getDataSource()).thenReturn(mockDataSource);
dao = new MyDao();
dao.setSqlMapClient(mockSqlMapClient);
On peut alors vérifier le comportement comme ceci:
Entity entity = new EntityImpl(4, "someField");
dao.save(entity);
ArgumentCaptor<Map> params = ArgumentCaptor.forClass(Map.class);
verify(mockSqlMapSession).insert(eq("insertEntity"), params.capture());
assertEquals(3, params.getValue().size());
assertEquals(Integer.valueOf(4), params.getValue().get("id"));
assertEquals("someField", params.getValue().get("name"));
assertNull(params.getValue().get("message"));
Alors que je peux voir votre logique, je peux envisager des fonctionnalités DAO qui pourraient bénéficier de l'unité essai. Par conséquent, je ne pense pas qu'il soit juste de dire que les DAO ne devraient pas faire l'objet de tests unitaires - tout dépend de la classe en question. – teabot