Quali sono gli svantaggi dei dispositivi di prova di modellazione (unità) in JSON invece di utilizzare ObjectFactories?

Question

Quali sono gli svantaggi dei dispositivi di prova di modellazione (unità) in JSON invece di utilizzare ObjectFactories?

#1 da (5 voti)
#2 da (1 voti)

2

Quando si scrivono i test Java per un'applicazione, siano essi test unitari o test di un ambito più ampio, la comunità java tende a modellare proiettori in termini di fabbriche di oggetti che producono dispositivi di uno stato definito.

es:

public class TestFixtureGeneratorA{
    static public A modelAState1(){
        A a = new A();
        a.setFoo(1);
        a.setBar("bar");
    }
    static public A modelAState2(){
        A a = new A();
        a.setFoo(2);
        a.setBar("baz");
    }
}

Considerando che, partendo da una prospettiva di metodologie BDD o Agile, sembrerebbe più sensato codificare i dispositivi in termini di scenario applicato e funzionalità o test.

es:

//file: src/test/resources/fixtures/scenarioA/interaction1/A.json
{
    foo: 1,
    bar: "bar"
}

//file: src/test/resources/fixtures/scenarioA/interaction2/A.json
{
    foo: 2,
    bar: "baz"
}

//file: src/test/resources/fixtures/scenarioA/interaction2/ids.json
[42, 101, 1337]

Quindi esegui il test nell'esecuzione fornita dall'interazione scenarioA X .

Ho visto questo genere di cose in team agili che modellano dal requisito aziendale al codice (ovvero mantengono uno stack BDD completo), nessuno dei quali negozi java) e una volta in un'applicazione di settore relativamente grande. Ma cercare di cercare la letteratura sulla pratica era infruttuoso. Sembrerebbe esserci un'implementazione a repository GitHub di Corballis che fornisce un'infrastruttura di test basata su annotazioni, simile a quella descritta sopra ma altre che il Web sembra privo di lavoro su questo argomento.

Vista la concisione di JSON e gli aspetti probabilmente migliori della formalizzazione / integrazione della meccanica di fissaggio basata su JSON, come mai non è stato discusso fino ad ora? Ci sono degli apparenti inconvenienti che mi mancano?

Nota: Ciò è tratto dall'esperienza personale in una moltitudine di progetti, principalmente in Java, altamente diversificati (alcuni in cui milioni di SLOC, altri hanno requisiti di performance folle, ecc.)

unit-testing design java json functional-testing

posta Kiriakos Krastillis 16.08.2017 - 10:13

fonte

2 risposte

Leggi altre domande sui tag unit-testing design java json functional-testing

Dare a più classi in una singola libreria lo stesso nome È possibile implementare l'overloading dell'operatore con variabile arity?

score 5 · Answer 1

Ho scritto test supportati da JSON in precedenza. Ecco gli svantaggi:

JSON non è controllato dal compilatore. Ciò significa che se aggiungi un campo ai tuoi modelli, non saprai che il tuo test JSON è rotto fino a quando non provi a eseguire i test e falliscono tutti.
JSON è più difficile da produrre rispetto al codice. Nel mio caso i nostri modelli erano piuttosto complessi, quindi avrei iniziato copiando un altro file JSON e ottimizzandolo.
JSON non può contenere commenti. Non è possibile documentare le caratteristiche importanti del file JSON che lo rendono appropriato per lo scenario.
Le integrazioni IDE per JSON non sono così avanzate come quelle per il codice. Ad esempio, posso passare alle definizioni e agli attributi nel codice, ma non posso farlo per JSON. Esiste una separazione tra il codice e i file JSON che potrebbe rendere difficile capire a colpo d'occhio quale file JSON viene utilizzato in un test. Qualche conoscenza di una convenzione di denominazione (nel tuo esempio) sarebbe necessaria, e dovrei navigare verso il file nel mio IDE o sistema operativo, e analizzarlo visivamente e con la ricerca testuale.

it would seem more sensible to encode fixtures in terms of their applied scenario and feature or test.

Che cosa ha a che fare con l'uso di JSON o no? È possibile produrre un oggetto su misura per la funzione in esame nel codice. Questa sarebbe la mia preferenza. È un compromesso perché il codice sarà probabilmente piuttosto lungo.

È possibile trattare codice di costruzione lungo creando builder per modelli complessi. Quindi invece di

A a = new A();
a.setFoo(2);
a.setBar("baz");

Potresti scrivere

A a = new ABuilder().foo(2).bar("baz").build();

O crea una fabbrica

A a = new AFactory(2, "baz").create();

score 1 · Answer 2

Se un test di integrazione (o test basato su JSON) fallisce, sai che qualcosa non va, ma non puoi essere sicuro quale componente abbia causato il problema. Potrebbe essere il parser / mapper JSON, il businesslogic o qualsiasi altro modulo coinvolto nel test.

Se un unittest (in isolamento con factorymethods) fallisce è probabile che il singolo modulo sotto test abbia causato il problema.

Per me l'informazione che "qualcosa non va" è abbastanza buona quindi preferisco usare testdata deserializzato (da JSON, csv o xml)

Questa domanda è un problema tra unittesting contro integrationtesting dove entrambi hanno i loro pro e contro.