Come evitare di utilizzare la dinamica durante la simulazione di un foglio Excel.works?

Question

Sto provando a simulare un foglio di calcolo Excel utilizzando NSubstitute o altri framework di simulazione e MSTest (Visual Studio 2010). Non sono sicuro se c'è un modo migliore di questo - e questo non funziona del tutto per il test:

Ecco un esempio (questo è tutto il codice prototipo in questo momento, e non molto pulita):

int[] lowerBounds = { 1, 1 }; 
int[] lengths = { 2, 2 }; 

//Initialize a 1-based array like Excel does: 
object[,] values = (object[,])Array.CreateInstance(typeof(object), lengths, lowerBounds); 
values[1,1] = "hello"; 
values[2,1] = "world";  

//Mock the UsedRange.Value2 property 
sheet.UsedRange.Value2.Returns(values); 

//Test: 
GetSetting(sheet, "hello").Should().Be("world"); //FluentAssertions 

Finora, così buono: questo passa se il metodo GetSetting è nello stesso progetto come mio test. Tuttavia quando GetSetting è nel mio progetto VSTO Excel-Addin, non riesce con il seguente errore nella prima riga della funzione GetSetting:

System.MissingMethodException: Error: Missing method 'instance object [MyExcel.AddIn] Microsoft.Office.Interop.Excel.Range::get_Value2()' from class 'Castle.Proxies.RangeProxy'. 

Per riferimento, il GetSetting afferra un valore da Columna nel foglio, e ritorna il valore nella colonna B.

public static string GetSetting(Excel.Worksheet sheet, string settingName) { 
    object[,] value = sheet.UsedRange.Value2 as object[,]; 
    for (int row = 1; row <= value.GetLength(1); row++) { 
    if (value[1, row].ToString() == settingName) 
     return value[2, row].ToString(); 
    } 
    return ""; 
} 

Il pezzo finale è interessante se io ridefinire la firma del mio metodo come segue:
pubblico GetSetting static String (dinamica foglio, stringa SettingName)
funziona nel progetto VSTO.

Quindi cosa sta succedendo e qual è il modo migliore per fare qualcosa del genere?

Grazie!

Answer 1

L'aggiornamento VS2012:Moq & Interop Types: works in VS2012, fails in VS2010?

Il primo: Qualcosa è cambiato:How do I avoid using dynamic when mocking an Excel.worksheet?

ho incontrato lo stesso problema oggetti di derisione di Excel utilizzando NSubstitute. La dinamica ha risolto il problema proprio come hai detto. Tuttavia volevo trovare la causa principale.

---

quando il progetto ha un riferimento a Microsoft.Office.Interop.Excel.Extensions.dll è necessario verificare se la tipi di proprietà Embed Interop è visibile. Se è questo significa il tuo targeting .Net 4.0 (che potrei intuire dalla parola chiave dinamica).

È possibile lasciare il targeting del progetto di test .Net 4.0 ma è necessario modificare lo scenario .Net di VSTO Project a 3.5. Poi ti probabilmente fare qualche cast esplicito e pienamente qualificarsi cose da sbarazzarsi di questi errori:

C# Office Excel Interop "oggetto non contiene la definizione di" errori, ecco un paio di esempi:

.Net 4.0:

if (tmpsheetName == xlApp.ActiveSheet.Name) 

.Net 3.5 equivalente

Worksheet activeSheet = (Worksheet)xlApp.ActiveSheet; 
if (tmpsheetName == activeSheet.Name) 

Un altro esempio:

rn.Select(); 

Net 4,0

xlApp.Selection.HorizontalAlignment = Constants.xlCenter; 
xlApp.Selection.Font.Bold = true; 
xlApp.Selection.Merge(); 

Net 3.5 equivalente

rn.HorizontalAlignment = Constants.xlCenter; 
rn.Font.Bold = true; 
rn.Merge(); 

---

Procedere alla correzione di tutti gli errori di sintassi .Net 3.5 vs 4.0 come illustrato negli esempi precedenti. Non dimenticare di rimuovere il tipo di parametro dynamic e sostituirlo con l'originale Worksheet. Finalmente spara di nuovo il Test e passerà !!!

Dato tutto il lutto che ho provato con Microsoft.CSharp.DLL in questo thread Sono del parere che collaudo i progetti di VSTO .Net 4.0 con Mocking Frameworks non funziona.

Answer 2

Si scopre che la simulazione di oggetti di interoperabilità COM molto complessi come l'oggetto Excel o l'oggetto InDesign che utilizza uno dei framework basati su castello (nsubstitute, ninject, ecc.), Non fornisce abbastanza avvio delle prestazioni. I tempi di esecuzione per i test sono ancora misurabili in secondi. (Moltiplicando questo valore per decine o centinaia di test, l'unità test è ancora troppo lenta per eseguire costantemente i principi TDD di test.)

Il test della logica di Excel deve quindi essere considerato un test di integrazione e, come l'oggetto Excel effettivo dovrebbe andare bene, rendendo il mocking non molto utile in uno scenario del genere. I risultati saranno molto più utili per testare un oggetto reale.

Il test su un livello di astrazione inserito tra Excel e l'applicazione consentirebbe un rapido test della logica dell'applicazione. E testare l'astrazione da layer-to-excel sotto test di integrazione dovrebbe essere sufficiente per testare l'applicazione.