Sviluppare con sicurezza senza un vero ambiente di sviluppo

Succede sempre nel mondo reale. Conosco un ragazzo che scrive app che controllano gigantesche serre agricole: ventilazione, riscaldamento, controllo dell'umidità, come lo chiami tu. Non ha una "serra di prova", ma ha un programma di simulazione fornito dalla società che costruisce i sistemi hardware attuali. Se il codice funziona correttamente con il simulatore, si presume che funzioni correttamente con l'attrezzatura reale. In rare occasioni il simulatore risulta essere sbagliato, ma questo è il problema della società hardware-serra da gestire, perché non sta simulando correttamente.

Queste sono situazioni in cui la documentazione dell'API, i documenti di controllo dell'interfaccia e gli emulatori sono di primaria importanza. In una società per cui ho lavorato in precedenza, in realtà ciò accadeva frequentemente all'interno di un progetto durante alcune fasi di integrazione in cui un segmento era pronto, ma altri erano indietro, ha lavorato su un'altra funzione o per qualche altra ragione che non potevano essere distribuiti l'ultima versione del loro segmento al nostro sistema di test. Quindi, sì, abbiamo effettivamente riprodotto fedelmente il nostro ambiente di produzione su cui abbiamo testato; tuttavia, in pratica, tutti i segmenti non sono mai stati pronti, ma le interfacce sono state concordate e bloccate prima dell'avvio dello sviluppo e sono stati creati emulatori che potrebbero in gran parte imitare il comportamento degli altri segmenti.

Come un'altra risposta affermava che l'emulatore è ciò che consentirà di eseguire i test prima della distribuzione. Un buon emulatore; tuttavia, dipende da interfacce e documentazione ben definite.

Sono sempre in queste situazioni.

Sicuramente non è necessario interagire con l'intera applicazione, ma probabilmente con alcune interfacce di qualche tipo. Assicurati di avere una documentazione confermata e dettagliata delle interfacce, quindi configura i mock di queste interfacce solo per verificare che il codice aggiunto / modificato funzioni come previsto.

Puoi anche fare un ibrido. Prova a replicare le parti che puoi fare piuttosto facilmente, quindi "connetti" ai sistemi reali (se questo è possibile nella tua situazione). L'ho fatto con un po 'di successo - in alcuni casi in cui la mia logica e il software del server sono stati eseguiti localmente, ma avevo ancora connessioni al sistema ERP reale per verificare le invocie ecc. Non ideale, ma raramente lo sono.

Dato che hai solo un sistema di produzione con cui lavorare - tieni presente che non puoi contare solo i tempi di sviluppo risparmiati sulla configurazione di una replica, ma devi tener conto del rischio commerciale di utilizzare un codice largamente non testato con dati aziendali in tempo reale. Il codice sarà meno affidabile del codice testato rispetto a una replica. I sistemi possono essere interrotti per qualche tempo? Possono essere ripristinati in caso di corruzione dei dati? Quanto costa?

Una buona pratica nelle aziende è quella di creare una replica (o forse più di una) della produzione nel momento in cui viene impostato l'ambiente di produzione. In quel momento, il costo aggiuntivo non sarà così grande.

Il nostro sistema funziona con un numero di grandi sistemi esterni. Combiniamo i seguenti approcci quando li testiamo se non disponiamo di una configurazione end-to-end completa:

• Registra-replay dati reali. registra dati reali (richieste / risposte da sistemi esterni reali), parametrizza se necessario e riproduci
• Costruisci o acquista un simulatore che funge da sistema esterno
• DSL per la generazione di dati di test. per i sistemi basati sui dati, scrivi DSL di alto livello per generare dati di test.