unit testing - software - Test unitario: perché l'argomento previsto è sempre il primo nei test di uguaglianza?




wikipedia test driven development (6)

Perché ogni framework di testing di unità (so di :) richiede che il valore atteso nei test di uguaglianza sia sempre il primo argomento:

Assert.AreEqual(42, Util.GetAnswerToLifeTheUniverseAndEverything());

assertEquals(42, Util.GetAnswerToLifeTheUniverseAndEverything());

eccetera.

Ora ci sono abbastanza abituato, ma ogni programmatore che cerco di insegnare per testare le unità fa l'errore di invertire gli argomenti, che capisco perfettamente. Google non ha aiutato, forse uno dei collaudatori di unità hard-core qui conosce la risposta?

https://code.i-harness.com


Beh, hanno dovuto scegliere una convention. Se vuoi invertire, prova i giocatori di Hamcrest. Servono per aumentare la leggibilità. Ecco un esempio di base:

import org.junit.Test;
import static org.junit.Assert.assertThat;
import static org.hamcrest.core.Is.is;

public HamcrestTest{
   @Test
   public void matcherShouldWork(){
       assertThat(   Math.pow( 2, 3 ),  is( 8 )  );
   }
}

Nessuno lo sa ed è la fonte di confusioni senza fine. Tuttavia, non tutti i framework seguono questo schema (per una maggiore confusione):

  1. FEST-Assert utilizza l' ordine normale :

    assertThat(Util.GetAnswerToLifeTheUniverseAndEverything()).isEqualTo(42);
    
  2. Hamcrest :

    assertThat(Util.GetAnswerToLifeTheUniverseAndEverything(), equalTo(42))
    
  3. ScalaTest realtà non fa una distinzione:

    Util.GetAnswerToLifeTheUniverseAndEverything() should equal (42)
    

Penso che sia perché JUnit è stato il precursore della maggior parte dei framework di testing unitario (non che fosse il primo framework di testing unitario, ma ha dato il via a un'esplosione nei test unitari). Da quando JUnit lo ha fatto in quel modo, tutti i quadri successivi hanno copiato questo modulo ed è diventato una convenzione.

perché JUnit ha fatto così? Non lo so, chiedi a Kent Beck!


Penso che sia solo una convention ora e come hai detto è stata adottata da "ogni framework di testing di unità (lo so)". Se si utilizza un framework sarebbe fastidioso passare a un altro framework che utilizza la convenzione opposta. Quindi (se stai scrivendo una nuova unità di test framework per esempio) sarebbe preferibile anche per te seguire la convenzione esistente. Credo che ciò derivi dal modo in cui alcuni sviluppatori preferiscono scrivere i loro test di uguaglianza:

if (4 == myVar)

Per evitare incarichi indesiderati, per errore, scrivendo uno "=" anziché "==". In questo caso il compilatore catturerà questo errore e eviterete un sacco di problemi nel tentativo di correggere un bug di runtime strano.


Sembra che la maggior parte dei primi quadri usati si aspettassero prima del reale (per qualche ragione sconosciuta, però, il lancio dei dadi forse?). Tuttavia, con lo sviluppo dei linguaggi di programmazione e una maggiore fluidità del codice, quell'ordine si è invertito. Le interfacce più fluenti di solito cercano di imitare il linguaggio naturale e le strutture di testing unitario non sono diverse.

Nell'affermazione, vogliamo assicurare che alcuni oggetti soddisfino alcune condizioni . Questa è la forma del linguaggio naturale, come se dovessi spiegare il tuo codice di test che probabilmente diresti

"In questo test, mi assicuro che il valore calcolato sia uguale a 5"

invece di

"In questo test, mi assicuro che 5 sia uguale al valore calcolato".

La differenza potrebbe non essere enorme, ma spingiamola oltre. Considera questo:

Assert.That(Roses, Are(Red));

Sembra giusto. Adesso:

Assert.That(Red, Are(Roses));

Hm ..? Probabilmente non saresti troppo sorpreso se qualcuno ti dicesse che le rose sono rosse . Altrimenti, il rosso è rose , solleva domande sospette. Yoda , qualcuno?

Yoda sta facendo un punto importante: l'ordine invertito ti costringe a think .

Diventa ancora più innaturale quando le tue asserzioni sono più complesse:

Assert.That(Forest, Has.MoreThan(15, Trees));

Come cambieresti quello? Più di 15 alberi vengono trovati dalla foresta ?

Questa affermazione (fluidità come fattore trainante per la modifica) si riflette in qualche modo nel cambiamento che NUnit ha attraversato - originariamente ( Assert.AreEqual ) usato prima del reale (vecchio stile). Estensioni fluide (o per usare la terminologia NUnit, basata sui vincoli - Assert.That ) hanno invertito quell'ordine.


Sicuramente è logico mettere il valore atteso per primo, poiché è il primo valore conosciuto.

Pensaci nel contesto dei test manuali. Un test manuale avrà il valore previsto scritto, con il valore effettivo registrato successivamente.





unit-testing