我使用Xunit创建一个单元测试来测试一个调用SitecoreContext的方法,并且总是返回null。
我正在使用FakeDB作为网站上下文。
这是单元测试的方法:
public static Model GetModelData(object owner)
{
try
{
using (var context = new SitecoreContext())
{
string homePath = Sitecore.Context.Site.ContentStartPath;
Model = context.GetItem<Model>(string.Format("{0}/Configuration/Model", homePath));
}
}
catch (Exception ex)
{
Sitecore.Diagnostics.Log.Error("GetModelData() Exception: " + ex.InnerException, owner);
}
return backToTop;
}
我使用FakeDb创建了一个假的SiteContext并调用了该方法。这是我尝试过的:
var fakeSite = new Sitecore.FakeDb.Sites.FakeSiteContext(new Sitecore.Collections.StringDictionary
{
{ "name", "fakesite" }, { "database", "master" }, { "rootPath", "/sitecore/content/home" }
});
using (new Sitecore.Sites.SiteContextSwitcher(fakeSite))
{
var result = SomeClass.GetModelData(this);
result.Should().NotBeNull();
}
调试时,我得到var上下文返回null。有没有办法喜欢模仿Glassmapper SitecoreContext?或者这是不可能的,因为我从方法中引入了新的SitecoreContext?
答案 0 :(得分:3)
你究竟在这里测试什么? FakeDB? Sitecore的?看起来单元测试是为了锻炼玻璃而已。没有实际的逻辑被运用,没有记录任何假设。
此外,您在测试此问题时遇到困难并不奇怪,因为只有5行代码存在如此多的依赖关系。当您将测试集中在 代码上时,单元测试会变得非常容易。没有必要为Sitecore,Glass和FakeDB编写单元测试 - 这不是你的工作。您需要重新构建此代码,以便依赖项(Glass上下文,起始路径和诊断记录器)作为处理的输入 - 通常是ctor
的参数。这样您就可以控制被测代码的参数,而不是依赖于您通过使用静态继承的隐式行为。毫无疑问,Glass中埋藏的代码依赖于你没有正确模拟的HttpContext,这就是为什么它不起作用的原因。删除对静态成员的调用,而不是将这些值传递给您的代码将允许您在代码测试时轻松地模拟它们,并且您根本不会遇到这些类型的问题。
我强烈建议您完全重新考虑您的单元测试策略,因为测试如上所述会浪费精力。
答案 1 :(得分:1)
尝试使用Db实例包装代码。
类似的东西:
[TestCase]
public void FooTest()
{
using (var db = new Db { })
{
var fakeSite = new Sitecore.FakeDb.Sites.FakeSiteContext(new Sitecore.Collections.StringDictionary
{
{ "name", "website" }, { "database", "web" }
});
using (new Sitecore.Sites.SiteContextSwitcher(fakeSite))
{
Sitecore.Context.Site.Name.Should().Be("website");
Sitecore.Context.Site.Database.Name.Should().Be("web");
}
}
}