Si applicano le stesse buone pratiche per la scrittura di unit test per applicazioni esterne a Windows Azure. Se si dispone di una dipendenza esterna rispetto a ciò che si sta testando, tale dipendenza dovrebbe essere derisa e iniettata per il test dell'unità granulare. Ad esempio, quando utilizzo le code di archiviazione di Windows Azure, ad esempio, avrò un'interfaccia che uso per interagire con la coda stessa, quindi nel mio codice che consuma il servizio in coda posso prendere in giro il sottosistema usando l'interfaccia e utilizzare la dipendenza iniezione per iniettare la simulazione. Ciò elimina la necessità di gestire effettivamente l'emulatore durante i test unitari. Per la maggior parte, l'effettiva implementazione concreta del codice che lavora con la coda non è molto più di un involucro molto sottile.
Io personalmente non scatto per una copertura di prova del 100%, quindi potrei non avere test di unità diretti che utilizzino l'implementazione concreta dei wrapper. In molti casi cerco di avere test di integrazione che esercitino questi wrapper ed esercitino più aspetti del sistema lavorando insieme. In alcuni casi, è possibile eseguire i test di integrazione nell'emulatore (ad esempio per le operazioni di archiviazione), ma in alcuni casi è sufficiente che vengano eseguiti con accesso all'ambiente Windows Azure (nel caso dell'utilizzo di ACS o bus di servizio).
Idealmente si desidera disporre di una serie di script che è possibile eseguire per creare una serie minima di server di prova in Azure, distribuire la soluzione ed eseguire i test di integrazione che non possono essere eseguiti nei locali. Quindi ottieni i risultati e chiedi allo script di chiudere tutto (o, facoltativamente, di lasciarlo in esecuzione se necessario). Quindi esegui la suite di test di integrazione che utilizza questi script abbastanza spesso per rilevare i problemi, ma sicuramente non è necessario eseguirli ogni volta che controlli qualcosa, a meno che tu non sia soddisfatto di eseguire l'ambiente di test tutto il tempo. Se stai bene con il costo di un ambiente di test semi-permanente in esecuzione in Azure, assicurati di avere gli script per una distribuzione di aggiornamento piuttosto che una cancellazione e ridistribuisci per ridurre un po 'il costo (il risparmio sarebbe relativo alla frequenza con cui la distribuzione avviene).
Credo che questa domanda sia molto soggettiva in quanto è probabile che si ottengano pareri diversi.
Voglio pareri diversi, quindi posso vedere quali diverse opzioni ci sono e quali sono le "migliori pratiche" (che possono differire per risposta) – mrtentje