Ci sono molte riflessioni sui test di diagnosi interna all'interno di un'applicazione aziendale?

What are the pros and cons of diagnosis testing - tests run built into the application (perhaps through a command line API or something) that would allow a system to check it's internal connections (database, middleware, filesystem etc) and confirm that everything it expects to work is correct?

Pro

• Consente agli addetti alla distribuzione di eseguire i test anziché attendere fino a tarda notte per testare l'applicazione.
• Ti offre un altro ostacolo da eliminare prima che il boss sia incazzato.

Contro

• È più manutenzione.
• È un altro endpoint esposto da inserire, che ha i suoi problemi di sicurezza.
• Non è necessario.

Ok, ho buttato quest'ultimo qui. Nella mia esperienza ...

• Se il tuo ambiente di test ha seguito le best practice e la produzione speculare, questo non sarebbe un problema.
• Se qualcuno fuma ha testato la distribuzione in produzione, questo non sarebbe un problema.
• Se potessi scrivere i test per verificare correttamente quella roba, perché non lo stai facendo già nel codice e includendo la causa dell'errore nei tuoi errori?
• E in realtà, come vanno gli assegni successivi alla distribuzione per salvare il tuo sistema una volta rotto?

Non posso commentare, quindi dovrò rispondere qui. Robert ha qualcosa con i suoi commenti. Questo sembra essere un problema di gestione e comunicazione e meno un test. Quindi il management dovrebbe puntare il dito contro se stesso o semplicemente superarlo, puntando le dita non fa molto per rendere il prodotto migliore e fa sì che le persone formino i lati. / Soapbox

Per quanto riguarda il test, ci sono molte metodologie che corrispondono a questo. Metodi come Test Driven Development lo collocano anche prima, prima che venga scritto il codice di produzione. Scrivi il test che soddisfa le tue specifiche, quindi scrivi il codice per passarlo. Questi test possono essere lasciati e resi accessibili per future spinte / fusioni del codice come livello base di accettazione, purché non abbiano problemi di sicurezza relativi ai dati, naturalmente. Io personalmente uso questo metodo nella mia organizzazione nel nostro ambiente CI e funziona alla grande.

I principali svantaggi dell'uso di qualcosa di simile quando sono distribuiti in un ambiente di produzione sono principalmente la sicurezza (se hai esposto una nuova superficie di attacco attraverso uno dei ganci di prova), o prestazioni a causa di uso eccessivo, cicli o registrazione eccessiva . Il valore di tutte le informazioni aggiuntive che questo può fornire è comunque un grosso controllo nella categoria "pro". Fornire qualcuno effettivamente utilizza le informazioni, ovviamente. Ma questo è un casino in cui non entrerò.

Lo fai sembrare come se questa applicazione aziendale fosse un'applicazione web. Raramente, gli ambienti di prova sono esattamente specchi di produzione. Anche se esiste un ambiente di pre-produzione tra test e prod, è una sfida mantenerlo come un mirror esatto di prod, specialmente in un ambiente aziendale in cui potrebbero esserci team diversi responsabili della manutenzione di ciascun ambiente. Tutti i test nel mondo potrebbero non averlo rilevato prima di andare in produzione.

Quello che stai suggerendo è molto simile a una pagina di controllo sanitario comune.

Contro:

• Molti sviluppatori potrebbero ritenere che sia una perdita di tempo
• Le persone potrebbero dimenticare che esiste e non usarlo
• Tutto ciò che Telastyn ha menzionato

Pro:

• Permette di controllare al volo tutti i principali file di configurazione e punti di integrazione
• Velocizza il trouble-shooting immensamente. Il personale di supporto può spesso diagnosticare problemi prima di coinvolgere il team di sviluppo.
• Consente la convalida preliminare da completare prima della produzione di fumo anche il test è iniziato

Personalmente, sono un grande fan di questi tipi di test. Rendono la mia vita di tester molto più semplice. Anche lo staff di supporto e gli sviluppatori tendono ad apprezzare molto queste pagine dopo averne bisogno una volta. Può fare la differenza del mondo quando si risolvono i problemi.

La diagnosi interna IMHO può essere una buona cosa - quando viene eseguita correttamente e in un modo che mostri potenziali errori, che altrimenti rimarrebbero non rilevati. Ma penso che il tuo esempio mostri un caso in cui normalmente non dovrebbe essere applicato. Il test di validità di una connessione al database non richiede in alcun modo un ulteriore sforzo di programmazione da parte di uno sviluppatore di applicazioni: si tratta di un test che il framework del database sottostante deve eseguire autonomamente ogni volta che viene eseguita una query sul database - nel caso in cui la connessione sia interrotta, dovrebbe comportare il lancio di un'eccezione o una riconnessione automatica (corretta gestione degli errori in ogni applicazione ipotizzata, che è una cosa diversa).

Tuttavia, un buon test di diagnosi consiste nel controllare la versione del database (schema) o il livello di patch, nel caso in cui vi siano delle dipendenze tra la versione dell'applicazione e la versione del database. Tale controllo può essere eseguito ogni volta che viene stabilita una connessione db. Tale test richiede che tu abbia qualcosa come un numero di versione memorizzato nel tuo database, che viene aggiornato correttamente ogni volta che aggiorni il tuo schema db.

Quando stai provando a costruire un sistema fail-safe, la diagnosi interna può essere una cosa, ma IMHO più importante è la ridondanza: il tuo esempio

the Manager is very angry as a system has fallen over after a new version of code was deployed

mostra una situazione in cui qualcuno non si aspettava errori durante l'aggiornamento di un sistema. Si tratta di un approccio totalmente sbagliato: tutti devono (!) Aspettarsi un fallimento in una situazione del genere e dovrebbero avere preventivamente adeguate misure preventive, come un adeguato backup di tutti i dati e le applicazioni della versione precedente o una simulazione del processo di ripristino da rendere sicuro che funzioni ed è abbastanza veloce. Questo include per lo più misure organizzative come non inviare tutti i tuoi amministratori nelle festività subito dopo tale aggiornamento, ed eseguire successivamente test sufficienti per assicurarsi che il sistema funzioni come previsto.

Qualsiasi tipo di diagnosi (interna o esterna) non può impedirti di fallire, ma può aiutare a rilevare errori precedenti.

Ritengo che le applicazioni o il sistema di livello enterprise debbano avere monitoraggio e diagnostica come funzionalità di progettazione di base. Questi requisiti non funzionali sono assolutamente necessari. Può essere ottenuto in molti modi da passivi (come la scrittura di registri eventi, registrazione diagnostica, esposizione di contatori delle prestazioni ecc.) A qualche tipo di Admin Dashboard attivo e fino alle API come hai menzionato. per esempio. L'applicazione di punta di Microsoft StockTrader ha questo tipo di monitoraggio della salute integrato ed è una buona architettura di riferimento. Coloro che praticano Consegna continua hanno concetti come il sistema immunitario dove, se alcuni controlli predefiniti falliscono, allora un rollback automatico è eseguita.