Sto per scrivere un programma e test (s) per questo. Questa domanda riguarda come strutturare il test di integrazione di livello più alto.
Al livello più alto, il programma principale prende una porzione di dati e genera un altro blocco; in particolare, prende un intero carico di dati aziendali come salari, costi dei materiali e così via da un file di configurazione o simili e produce un singolo file XML che elenca i prodotti, i loro prezzi, i dati specifici del prodotto, i dati su gruppi di prodotti, e molte altre cose.
Quindi come dovrebbe essere questo test di integrazione di primo livello?
Mi associo all'idea di scrivere test di livello superiore prima di ogni altra cosa, agendo come una specifica dell'interfaccia per il codice da programmare e in misura molto minore per catturare bug (poiché ad un dato livello, l'insieme di i test dovrebbero essere più accurati del livello precedente, quindi la maggior parte dei test dovrebbe essere eseguita in test unitari.)
Sto pensando di scrivere qui un singolo test di integrazione di primo livello: alimentarlo con un file di configurazione completo, quindi verificare che l'output XML sia come previsto.
Quindi, usando PHPUnit, avrei una singola classe TestCase con un singolo metodo test() . E quel metodo affermerebbe ogni tag XML previsto e il loro contenuto, e fallirà anche se ci sono tag inattesi. Ma solo una combinazione di input di configurazione verrebbe testata. (O forse un paio se sembra davvero necessario in un secondo momento).
In questo modo, il test servirà come indicatore per mantenere gli sforzi di programmazione focalizzati sull'obiettivo finale.
E il test sarebbe facile da leggere (e mantenibile?) poiché consiste solo in un metodo di test molto piccolo, un file di configurazione di input e un file XML di output previsto.
Il problema è che ho letto che i test dovrebbero essere sempre mantenuti piccoli - ad es. al massimo una manciata di asserzioni per metodo di prova. Ma poi testare un intero file XML come questo sarebbe un odore di codice?