Come scrivere un test di integrazione in NUnit?

Question

Siamo due studenti che scrivono la nostra tesi di laurea e abbiamo sviluppato un'applicazione per Windows, che dovrebbe essere in grado di aiutare un ristorante in vari processi di comunicazione. Fondamentalmente, dovrebbe essere in grado di presentare le informazioni sull'ordine dal momento in cui un ospite lo invia ad esso è servito.

Abbiamo omesso di testare durante lo sviluppo ma abbiamo deciso di scrivere test unitari ora. Tuttavia, abbiamo scoperto che il test più adatto che possiamo scrivere sul nostro sistema ora sono test di integrazione perché tutti i metodi nelle nostre classi sono legati alle stored procedure SQL tramite LINQ to SQL. Siamo consapevoli dell'uso di stub per eliminare una dipendenza da un database, ma quando il nostro database è già implementato insieme a tutte le funzioni, abbiamo pensato che ci avrebbe dato più valore per testare diversi metodi insieme come test di integrazione.

Come visto nel codice qui sotto abbiamo cercato di seguire le linee guida per un test unitario, ma è questo il modo giusto per scrivere un test di integrazione?

[Test] 
public void SendTotalOrder_SendAllItemsToProducer_OneSentOrder() 
{ 
    //Arrange 
    Order order = new Order(); 
    Guest guest = new Guest(1, order); 
    Producer producer = new Producer("Thomas", "Guldborg", "Beverage producer");    
    DataGridView dataGridView = new DataGridView { BindingContext = new BindingContext() }; 
    order.MenuItemId = 1; 
    order.Quantity = 1; 

    //Act 
    guest.AddItem(); 
    dataGridView.DataSource = guest.SendOrderOverview(); 
    guest.SendOrder(dataGridView); 
    dataGridView.DataSource = producer.OrderOverview(); 
    var guestTableOrder = producer.OrderOverview() 
     .Where(orders => orders.gtid == guest.GuestTableId) 
     .Select(producerOrder => producerOrder.gtid) 
     .Single(); 

    //Assert 
    Assert.That(guestTableOrder, Is.EqualTo(guest.GuestTableId)); 
} 

Answer 1

Sì, in generale, questo è come scrivere un test unitario/test di integrazione. Si osserva alcune importanti linee guida:

• distinta Act-Disporre-Assert passi
• Il nome del test descrive questi passi (forse dovrebbe avere qualcosa di simile "ShouldSendOneOrder" alla fine, "dovrebbe" è comunemente usato per descrivere Assert).
• One Assert per test.

suppongo che voi obbedite anche altre linee guida:

• I test sono indipendenti: non cambiano stato persistente, in modo da non influenzare gli altri test.
• Test casi di utilizzo realistico: non organizzare costellazioni che violano la logica aziendale, non eseguire azioni impossibili. Oppure: imita la vera applicazione.

Tuttavia, vedo anche cose che sollevano le sopracciglia.

• Non è chiaro che agiscono si prova. Penso che alcuni "atti" appartengano alla fase organizzativa.

• Un metodo come producer.OrderOverview() mi fa sospettare che gli oggetti del dominio eseguano l'interazione del database. In tal caso, ciò violerebbe l'ignoranza di persistenza . Penso che ci dovrebbe essere un servizio che presenta questo metodo (ma vedi sotto).

• Non è chiaro il motivo per cui il test dataGridView.DataSource = producer.OrderOverview(); è necessario. Se lo è, questo aggrava solo il punto più serio:

• Business logic e UI sono impigliati !!

  • metodo come guest.SendOrderOverview() e producer.OrderOverview() sono puzzolente: perché un oggetto di dominio saper presente suo contenuto? Questo è qualcosa che dovrebbe essere responsabile di un presentatore (MVP) o un controller (MVC) o un modello di visualizzazione (MVVM).
  • Un metodo come guest.SendOrder(dataGridView) è malvagio. Lega il livello del dominio al framework dell'interfaccia utente. Questa dipendenza fissa è abbastanza malvagia, ma ovviamente è necessario anche i valori della vista griglia in questo metodo. Quindi la logica di business richiede una conoscenza approfondita di alcuni componenti dell'interfaccia utente. Ciò viola il principio - non chiedere. guest.SendOrder dovrebbe avere parametri semplici che indicano come eseguire la sua attività e il dominio non deve avere qualsiasi riferimento a qualsiasi struttura di interfaccia utente.

Si dovrebbe affrontare quest'ultimo punto. Rendi il tuo obiettivo eseguire questo test senza alcuna interazione con DGV.

Answer 2

Se si continua a associare sql in classe, il test non è un grosso problema.

È possibile utilizzare questo metodo quando la logica del programma è molto semplice, ma suggerisco di studiare The Repository Pattern, in quanto la logica diventa più complessa.