2011-03-18 10 views
7

interfaz de servicio: Implementaciónservicio en la primavera de MVC usando EasyMock

public List<UserAccount> getUserAccounts(); 
public List<UserAccount> getUserAccounts(ResultsetOptions resultsetOptions, List<SortOption> sortOptions); 

Servicio:

public List<UserAccount> getUserAccounts() { 
    return getUserAccounts(null, null); 
} 
public List<UserAccount> getUserAccounts(ResultsetOptions resultsetOptions, List<SortOption> sortOptions) { 
    return getUserAccountDAO().getUserAccounts(resultsetOptions, sortOptions); 
} 

¿Cómo puedo probar esta usando EasyMock o cualquier otra metodología de prueba viable? código de muestra será apreciado. Para el simulacro fácil pasar objetos como parámetros muy confusos. ¿Alguno explica claramente cuál es el mejor enfoque para probar la capa de servicio? interfaz de servicio de prueba se considerará prueba de unidad o prueba de integración?

+1

Hacer una pregunta el viernes por la tarde no es una buena idea ya que nadie ve esto en fin de semana y en el lunes estarán ocupados con nuevas preguntas. Estoy seguro de que algunos gurús de pruebas seguramente conocen la respuesta y la explicación de esto y me ayudarán. – kneethan

Respuesta

4

Aquí tiene, suponiendo que esté utilizando JUnit 4 con anotaciones:

import static org.easymock.EasyMock.createStrictMock; 
import static org.easymock.EasyMock.expect; 
import static org.easymock.EasyMock.replay; 
import static org.easymock.EasyMock.verify; 

public class UserAccountServiceTest 

    private UserAccountServiceImpl service; 
    private UserAccountDAO mockDao; 

    /** 
    * setUp overrides the default, We will use it to instantiate our required 
    * objects so that we get a clean copy for each test. 
    */ 
    @Before 
    public void setUp() { 
      service = new UserAccountServiceImpl(); 
      mockDao = createStrictMock(UserAccountDAO.class); 
      service.setUserAccountDAO(mockDao); 
    } 

    /** 
    * This method will test the "rosy" scenario of passing a valid 
    * arguments and retrieveing the useraccounts. 
    */ 
    @Test 
    public void testGetUserAccounts() { 

      // fill in the values that you may want to return as results 
      List<UserAccount> results = new User(); 

      /* You may decide to pass the real objects for ResultsetOptions & SortOptions */ 
      expect(mockDao.getUserAccounts(null, null) 
       .andReturn(results); 

      replay(mockDao); 
      assertNotNull(service.getUserAccounts(null, null)); 
      verify(mockDao); 
    } 

} 

También puede encontrar this article útil sobre todo si está utilizando JUnit 3.

Refer this para una ayuda rápida en JUnit 4

Espero que ayude.

+0

Gracias por su respuesta, así que cada vez que encontramos algunos parámetros de objetos que no son relevantes para la prueba unitaria, los hacemos nulos en la llamada esperada. – kneethan

+0

¿Realmente tiene sentido escribir un caso de prueba unitario para estos dos métodos? para mí no es más que delegar a la capa DAO, ¿aún tenemos que probar? – kneethan

+0

Para obtener un getter simple, puede que no; sin embargo, si tiene condiciones y una ruta if/else en el método de servicio, entonces lo haría. Otra cosa, el propósito de la prueba unitaria es probar la unidad de una sola unidad (Servicio en este caso), no Servicio y DAO (Eso se llama prueba de integración). En cuanto a pasar nulo, elegí la prueba más simple. Pero como se incluye en el comentario, debe crear esos objetos (ResultSetOptions, SortOptions) también. Si no están listos (es decir, solo interfaces y no hay implementación), entonces puede que tenga que usar la implementación simulada para ellos también. – Nilesh

Cuestiones relacionadas