Есть ли способ определить, выполняется ли какой-либо код в рамках модульного тестирования Silverlight?

Question

Есть ли способ сказать во время выполнения, запускается ли код из сборки Silverlight Unit Test Framework? (Для контекста я надеюсь создать NinjectModule, который будет связывать DomainClient с FakeDomainClient , если мы запускаем проект модульного теста, но в противном случае привязываем к WebDomainClient.)

Answer 1

Лучший способ - совсем не знать об этом, имея хороший дизайн, который позволяет вам перепривязывать DomainClient в ваших тестах, а не решать в своем производственном коде, какой экземпляр он должен использовать. Это освобождает ваш рабочий код от тестового кода и снижает вероятность странных исключений.

Хаком было бы создание статического класса со статическим свойством UnitTestRunning, которое по умолчанию имеет значение false и имеет значение true в инициализаторе теста и считывается в модуле.

Answer 2

Это немного грубо, но одной из возможностей было бы протестировать одно из свойств (возможно, LocalPath) из System.Windows.Application.Current.Host.Source. Вам необходимо проверить, был ли XAP-файл размещения XAP из вашего тестового проекта или XAP для вашего приложения. Это, очевидно, сделало бы предположение об именах файлов XAP, что делает его немного ломким (даже если вы извлекаете что-то из пространства имен, имя файла XAP фактически настраивается в свойствах проекта в любом случае - поэтому нет гарантии, что оно всегда будет совпадать ).

Кроме того, вы можете проверить значение System.Windows.Application.Current.RootVisual. Опять же, вам, конечно, нужно иметь в виду, что нет никакой гарантии, что будущие версии Silverlight Unit Test Framework будут использовать тот же Microsoft.Silverlight.Testing.Client.TestPage (хотя реализация проверки, возможно, как метод статического расширения для Например, класс приложения будет, по крайней мере, означать, что вы можете ограничить свои изменения в ваших методах расширения в будущем по мере необходимости).

Другой альтернативой может быть использование HTML-моста и тестирование одного из свойств из System.Windows.Browser.HtmlPage.Document.DocumentUri. Это кажется хуже, чем первые два варианта, потому что предположения о размещении имен uris / страниц, вероятно, будут даже хуже, чем предположения о конкретном UIElement, используемом для Приложения, или имени файла XAP.

Любое решение, основанное на именах файлов XAP или именах страниц хостинга, вероятно, в любом случае должно полагаться на имена, основанные на соглашениях, поскольку вы захотите использовать эту технику в своих тестах для нескольких модулей / проектов.

Лучшей альтернативой, вероятно, будет использование System.Windows.Application.Current.Host.InitParams. Вы можете потенциально передать определенный параметр на странице в вашем тестовом проекте, и в конечном итоге ваш код протестирует значение этого конкретного параметра. Преимущество этого заключается в том, что для имени XAP-файла или имени страницы / URI / страницы не требуется никакого конкретного RootVisual или какого-либо специального соглашения об именах.