Как избежать динамического использования при издевательстве Excel.workheet?

Question

Я пытаюсь высмеять электронную таблицу Excel, используя NSubstitute или другую насмешливую структуру и MSTest (Visual Studio 2010). Я не уверен, если есть лучший способ, чем это - и это не совсем работает для тестирования:

Вот пример (это весь код прототипа прямо сейчас, и не очень чистый):

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 

До сих пор так хорошо: это проходит, если метод GetSetting равен в том же проекте как мой тест. Однако, когда GetSetting в моем проекте VSTO Excel-Addin, он терпит неудачу из-за ошибки на первой строке функции GetSetting:

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

Для справки, GetSetting захватывает значение из Columna в листе, и возвращает значение в столбце 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 ""; 
} 

Окончательный интересный кусок, если я переопределять подписи моего метода следующим образом:
общественности статической строки GetSetting (динамический лист, строка settingName)
он работает в проекте VSTO.

Итак, что же происходит, и что лучший способ сделать что-то подобное?

Спасибо!

Answer 1

Обновление VS2012:Moq & Interop Types: works in VS2012, fails in VS2010?

Первый: Что-то изменилось:How do I avoid using dynamic when mocking an Excel.worksheet?

я столкнулся с той же проблемой объекты Mocking Excel с помощью NSubstitute. Динамика разрешила проблему так же, как вы упоминаете. Однако я хотел найти основную причину.

---

Когда проект имеет ссылку на Microsoft.Office.Interop.Excel.Extensions.dll вам нужно проверить, если типы недвижимости Код Interop видна. Если это означает, что ваш таргетинг .Net 4.0 (что я могу угадать из ключевого слова dynamic).

Вы можете оставить проект Test нацеливание .Net 4.0, но вам нужно вам изменить структуру VSTO Project .Net обратно до 3.5. Тогда вы будете , вероятно, придется сделать некоторое явное приведение и полностью квалифицировать вещи избавиться от этих ошибок:

C# Office Excel Interop «объект не содержит определение для» ошибки, вот пара примеров:

.Net 4.0:

if (tmpsheetName == xlApp.ActiveSheet.Name) 

.Net 3.5 эквивалентно

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

Другой пример:

rn.Select(); 

.Net 4,0

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

.Net 3.5 эквивалентно

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

---

Приступайте к исправлению всех синтаксических ошибок .Net 3.5 vs 4.0 в соответствии с приведенными выше примерами. Не забудьте удалить тип параметра dynamic и заменить его оригиналом Worksheet. Наконец, снова запустите тест, и он пройдет !!!

Учитывая все горе, которое я испытал с Microsoft.CSharp.DLL в этом thread Я считаю, что тестирование VSTO .Net 4.0 проектов с Mocking Frameworks не работает.

Answer 2

Оказалось, что издевательства над сложными объектами COM-взаимодействия, такими как объект Excel или объект InDesign, с использованием любой из основанных на замке фреймворков (nsubstitute, ninject и т. Д.) Не обеспечивают достаточной загрузки производительности. Время работы для тестов по-прежнему измеряется в секундах. (Умножая это на десятки или сотни тестов, тесты на модуле все еще слишком медленны, чтобы работать в соответствии с принципами тестирования TDD постоянно.)

Тестирование логики Excel затем следует считать интеграционным тестом и, как таковой, фактический объект Excel должен быть хорошим, делая насмешливым не очень полезным в таком сценарии. Результаты будут гораздо более полезными для тестирования фактического объекта.

Тестирование уровня абстракции между Excel и приложением позволит быстро протестировать логику приложения. И тестирование уровня абстракции для Excel при интеграционном тестировании должно быть достаточным для тщательной проверки приложения.