2011-03-18 4 views
7
Interfaccia

Servizio: Attuazioneservizio di test di livello nella MVC primavera utilizzando EasyMock

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

Servizio:

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

Come posso verificare questo utilizzando EasyMock o qualsiasi altra metodologia di test praticabile? codice di esempio sarà apprezzato. Per il facile derisione passare oggetti come parametri molto confusi. Qualcuno spiega chiaramente qual è l'approccio migliore per testare il livello di servizio? l'interfaccia del servizio di test sarà considerata come test unitario o di integrazione?

+1

Fare domande venerdì sera non è una buona idea dato che nessuno lo guarda nel fine settimana e lunedì saranno impegnati con nuove domande. Sono sicuro che alcuni guru dei test conosceranno sicuramente la risposta e la spiegazione per questo e mi aiuteranno. – kneethan

risposta

4

Qui si va, supponendo che si sta utilizzando JUnit 4 con annotazioni:

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); 
    } 

} 

Si potrebbe anche trovare this article utile soprattutto se si utilizza JUnit 3.

Refer this per un aiuto rapido su JUnit 4

Spero che questo aiuti.

+0

Grazie per la vostra risposta, quindi ogni volta che incontriamo alcuni parametri dell'oggetto che non sono rilevanti per il test dell'unità, li rendiamo nulli nella chiamata prevista? – kneethan

+0

È davvero sensato scrivere un caso di test unitario per questi due metodi? per me non è altro che delegare a livello DAO, ma dobbiamo ancora testare? – kneethan

+0

Per un getter semplice non può, tuttavia, se le condizioni e il percorso/else nel metodo di servizio lo soddisfano. Un'altra cosa l'intero scopo del test unitario è di testare una singola unità (Servizio in questo caso) non Servizio e DAO (che si chiama test di integrazione). Come passare null, ho scelto il test più semplice. Ma come inserito nel commento, dovresti creare anche quegli oggetti (ResultSetOptions, SortOptions). Se non sono pronti (vale a dire solo interfacce e nessuna implementazione), potrebbe essere necessario utilizzare un'implementazione fittizia anche per loro. – Nilesh