Sono obbligato a scrivere test per un'API sul posto di lavoro per assicurarci di non romperlo mentre ci sviluppiamo. Finora, le soluzioni che escono sono le seguenti:
- codice "prod" e codice "devel" in esecuzione sullo stesso DB (con un dump del database di produzione);
- codice "prod" e codice "devel" in esecuzione sul proprio DB.
Entrambe le soluzioni richiedono un'applicazione stand-alone per fare una diff dei risultati dati da entrambi i codici. Quindi, mi viene anche richiesto di scrivere qualcosa che permetta di fare differenze tra JSON, XML o qualsiasi altro formato utilizzato dall'API.
Secondo me, questo è un pensiero eccessivo. Penso che sarebbe meglio scrivere semplici test funzionali che passino con successo e che saranno inclusi nel progetto del codice API. Man mano che sviluppiamo, eseguiremo semplicemente i test e sistemeremo cosa ha fallito il passaggio come in precedenza.
La mia soluzione era stata respinta da un collega perché non era giusto non efficiente per alcuni motivi specifici:
- abbiamo bisogno di dati reali;
- creare un set di dati per i test è impossibile;
- non vogliamo riscrivere i test ogni volta che cambiamo qualcosa;
- abbiamo bisogno di generare migliaia di url a caso;
- anche se non so cosa possa o non possa fare PHPUnit, penso che qualcosa di scritto in bash sarà più ottimizzato, o Python per trarre vantaggio dal multi-threading (!?).
Per me, sembra completamente privo di senso e manca totalmente lo scopo del test. In primo luogo, lo schema del nostro database è piuttosto semplice: un punteggio di tabelle denormalizzate con una manciata di colonne, molte di queste sono di tipo booleano. Quindi, scrivere un set di dati rilevante mi sembra abbastanza semplice.
In secondo luogo, penso che (potrei sbagliarmi) che il test riguarda la determinazione di ciò che il tuo codice dovrebbe fare in ogni circostanza possibile. Non è necessario scrivere più di pochi URL "hard coded" (non generati casualmente) che testeranno ciascuno di questi casi.
In terzo luogo, riscriviamo i test in quanto è richiesto il comportamento del cambiamento di codice e un vantaggio di per sé, non qualcosa da evitare perché sembra essere qualcosa di naturale.
Infine, i miei pensieri sono anche guidati dal fatto che, per quanto riguarda l'autodidatta che conosco, non ho mai sentito parlare del tipo di test che vogliono che io scriva. Per me, questo è un indizio del fatto che stiamo parlando di qualcosa di veramente specifico che richiede una soluzione ancora più specifica (ma la nostra API è piuttosto semplice e soprattutto di sola lettura), o che ci stiamo sbagliando di grosso. Il mio collaboratore, che è il più affidabile del mio superiore, non sembra esperto nei test ... Sono stato rimproverato per aver cercato di chiarire che quello che chiamano "unit test" è in realtà qualcosa tra l'integrazione e il test funzionale con un enorme fumo (sì, davvero), e che dovremmo chiarire cosa vogliamo testare per quale scopo, o che non dovremmo testare metodi privati. Ha risposto con rabbia che i suoi test funzionano e che sto diventando "troppo teorico" e non dovrei ascoltare "persone che amano le parole portmanteau" perché è inutile ... Detto questo, semplicemente non mi fido di lui, in almeno questo punto!
Qualcuno ha mai dovuto scrivere tali test che erano davvero le migliori soluzioni? Perché è stato il migliore? Dovrei cercare di rendere più chiaro il mio punto di vista e / o prendere il mio superiore per "forzare" a provare prima la mia "soluzione di base"?
Grazie,