it-swarm.com.de

Wie kann ich meinen REST Web-Service) einem Unit-Test unterziehen?

Ich bin neu im Unit-Test, ich habe eine REST Web-Methode, die nur DB aufruft und ein DTO auffüllt. Pseudocode ist

public object GetCustomer(int id)
{
  CustomerDTO objCust = //get from DB
  return objCust;
}

Mein Zweifel ist, wie man Tests für diese Methoden und die Art der Tests (Integration/Unit) schreibt, die eingeschlossen werden sollen. Und für Unit-Tests muss es die DB treffen. Wenn dies der Fall ist und ich eine Kunden-ID übergebe und nur wenige Aussagen mache, können sich die Daten möglicherweise ändern und zu Fehlern führen.

Ich glaube, mir fehlt hier etwas, um diese Konzepte zu verstehen.

16
Sunny

Während des Komponententests wird nicht erwartet, dass Sie mit einer Datenbank oder zumindest nicht mit einer Datenbank testen, die Sie nicht für den Komponententest vorbereitet haben. Das Testen mit einer Datenbank und als solches das gleichzeitige Testen verschiedener Ebenen Ihrer Anwendung wird im Allgemeinen als Integrationstests angesehen . Bei Unit-Tests sollten Sie nur testen, was Ihre Methode tut, was sie abhängig von verschiedenen Parametern zurückgibt und wann (oder nicht) sie fehlschlagen sollte.

Es wird sehr erwartet, dass Sie in Ihrer Methode [~ # ~] x [~ # ~] Methoden aus anderen Klassen aufrufen. Sie testen diese [~ # ~] x [~ # ~] Methoden nicht. Sie müssen also mock diese Methoden.

Ich nehme an, Sie schreiben Ihren Code in Java. In diesem Fall haben Sie großartige spöttische Frameworks wie Mockito , die für Sie hilfreich sein können. Unabhängig davon, ob Sie ein spöttisches Framework verwenden oder nicht, ich sage nur, dass Sie dadurch viel Zeit sparen, und das von mir erwähnte ist zumindest nicht kompliziert.

Wenn Sie nur Ihr eigenes Modell zum Experimentieren schreiben möchten, nehmen Sie an, dass Sie die folgende CustomerRepository -Klasse haben:

public class CustomerRepository {
 public CustomerDTO getCustomer(int id) {
   ...
 }
}

Sie können Ihre eigene verspottete und schmutzige CustomerRepository Klasse folgendermaßen schreiben:

public class MockedCustomerRepository extends CustomerRepository {
 public boolean bThrowDatabaseException;
 public boolean bReturnNull;
 public boolean bReturnCustomerWrongId;
 public boolean bReturnCustomerWithId;
 public CustomerDTO getCustomer(int id) {
  if(bThrowDatabaseException) { 
    throw new DatabaseException("xxx"); 
  } else if(bReturnNull) { 
    return null; 
  } else if(bReturnCustomerWrongId) { 
    throw new CustomerNotExistException(id);
  } else if(bReturnCustomerWithId) { 
    return new CustomerDTO(id); 
  }
 }
}

Dann ersetzen Sie in Ihrem Testfall im Grunde Ihre "Standard" -Instanz von CustomerRepository durch eine verspottete Instanz, mit der Sie Ihre Methode auf verschiedene Ergebnisse von getCustomer testen können:

public class CustomerRestTest {
  public void testGetCustomer_databaseFailure() {
    MockedCustomerRepository dto = new MockedCustomerRepository();
    dto.bThrowDataBaseException = true;
    yRestClass rest = new MyRestClass();
    rest.dto = dto;
    rest.getCustomer(0);
    // depending on what you do in your getCustomer method, you should check if you catched the exception, or let it pass, etc.. Make your assertions here

  public void testGetCustomer_customerNotExist() {
    // etc.
  }
}

Im Allgemeinen sollte jede Testmethode nur eines testen. Dies hilft, Ihre Tests klein zu halten und sich auf eine Aufgabe zu konzentrieren.

Ich werde es wiederholen :-) Das Schreiben einer ganzen verspotteten Klasse dauert einige Zeit, wie Sie sehen. Erwägen Sie die Verwendung eines Spott-Frameworks. Je weniger man Code schreibt, desto weniger Fehler macht man , oder? Das Verspotten einer Methode, die eine Ausnahme auslöst oder einen bestimmten Wert für einen bestimmten Parameter zurückgibt, ist ein Kinderspiel und dauert 2 oder 3 Zeilen (mindestens mit Mockito).

Ich hoffe, das hilft beim Testen Ihrer REST -Methode.

18
Jalayn