UnitTest中的FakeItEasy Action参数,但仍然执行内部Action代码
FakeItEasy Action parameter in UnitTest, but still execute inner Action code
我目前正在为我添加到 ASP.NET 项目中的一些新功能做一些单元测试(不,这不是试驾设计)。我们使用 NHibernate 框架并使用 UnitTest Mock-ing 库 FakeItEasy
.
我有以下 class & 我想测试的方法:
public class Round
{
public static Round Create(List<Company> activeCompanies, Period period,
BusinessUser user, BusinessUser systemUser,
ISession session, IEntityQuery entityQuery,
RoundProcessBuilder processBuilder)
{
var round = new Round
{
Processes = new List<Process>();
Period = period,
CreationDate = DateTime.Now,
CreatedBy = user
};
// Save the Round in the DB so we can use it's Id in the Processes:
session.Save(round);
foreach (var company in activeCompanies)
{
var companyData = session.Get<CompanyData>(company.Id);
var processResult =
roundProcessBuilder.Build(
systemUser,
new CreateRoundProcessData(company, round, companyData),
entityQuery,
session);
processResult.HandleProcess(process =>
{
// serviceBus can stay null
process.Create(systemUser, DateTime.Now, session, null);
// No need to save the session here. If something went
// wrong we don't want halve of the processes being saved
round.Processes.Add(process);
// It's all or nothing
});
}
return round;
}
}
我主要想测试的是:当我使用这个Round#Create
方法时,假设有 100 个活跃的公司,它应该创建 100 个进程,并且每个进程应该包含 RoundId
.
到目前为止,这是我的单元测试:
[TestFixture]
public class RoundTest
{
private BusinessUser _systemUser;
private DateTime _creationDateRound1;
private List<Company> _activeCompanies;
private RoundProcessBuilder _roundProcessBuilder;
private ISession _session;
[SetUp]
public void Setup()
{
_creationDateRound1 = new DateTime(2015, 10, 5);
_systemUser = TestHelper.CreateBusinessUser(Role.Create("systemuser", "test",
Int32.MaxValue));
_activeCompanies = new List<Company>
{
TestHelper.CreateCompany();
};
_roundProcessBuilder = A.Fake<RoundProcessBuilder>();
_session = A.Fake<ISession>();
}
[Test]
public void TestCreateRoundWithoutPreviousRound()
{
var fakeExpectedRound = Round.Create(_activeCompanies, DateTime.Now.ToPeriod(),
_systemUser, _systemUser, _session, null, _roundProcessBuilder);
var fakeExpectedRoundData = RoundProcessData.Create(TestHelper.CreateCompany(),
fakeExpectedRound, new CompanyData());
var fakeExpectedProcess = new Process(_systemUser, null, "processName", null,
fakeExpectedRoundData, "controllerName", null);
var processSuccessResult = new ProcessSuccessResult(fakeExpectedProcess);
A.CallTo(() => _roundProcessBuilder.Build(null, null, null, null))
.WithAnyArguments()
.Returns(processSuccessResult);
A.CallTo(() => processSuccessResult.HandleProcess(A<Action<Process>>.Ignored))
.Invokes((Action<Process> action) => action(fakeExpectedProcess));
var round = Round.Create(_activeCompanies, _ceationDateRound1.ToPeriod(),
_systemUser, _systemUser, _session, null, _roundProcessBuilder);
Assert.AreEqual(_activeCompanies.Count, round.Processes.Count, "Number of processes");
Assert.AreEqual(round.Period.Quarter, Math.Ceiling(_creationDateRound1.Month / 3.0m), "Quarter");
Assert.AreEqual(round.Period.Year, round.Year, "Year");
// Test if each of the processes knows the RoundId, have the proper state,
// and are assigned to the systemuser
//foreach (var process in round.Processes)
//{
// var roundProcessData = process.ProcessData as RoundProcessData;
// Assert.IsNotNull(roundProcessData, "All processes should have RoundProcessData-objects as their data-object");
// Assert.AreEqual(roundProcessData.Round.Id, round.Id, "RoundId");
// Assert.AreEqual(process.Phase.State, PhaseState.Start, "Process state should be Start");
// Assert.AreEqual(process.AssignedTo, _systemUser, "AssignedTo should be systemuser");
//}
}
... // More tests
}
我的问题出在下面的代码上:
A.CallTo(() => processSuccessResult.HandleProcess(A<Action<Process>>.Ignored))
.Invokes((Action<Process> action) => action(fakeExpectedProcess));
它给出一个“The specified object is not recognized as a fake object.
”错误。
我有这部分代码的原因是因为没有它下面部分的 process
是空的:
processResult.HandleProcess(process => // <- this was null
{
process.Create(systemUser, DateTime.Now, session, null);
round.Processes.Add(process);
});
PS:我在我的 UnitTest 中取消注释 foreach 并进行额外检查,因为当我模拟 process
本身时它很可能毫无用处。我的主要测试是是否创建了进程并且根据给定的活跃公司添加到列表中。
您的问题似乎是您正试图将 "fake" 逻辑添加到一个实际上不是假的对象:
// You create this as an instance of ProcessSuccessResult:
var processSuccessResult = new ProcessSuccessResult(fakeExpectedProcess);
...然后继续尝试在此处添加条件:
A.CallTo(() =>
processSuccessResult
.HandleProcess(A<Action<Process>>.Ignored))
.Invokes((Action<Process> action) => action(fakeExpectedProcess));
为了完成最后一点,变量 processSuccessResult
需要是接口的假实例,以便 FakeItEasy 可以使用它,并应用您想要的逻辑。
我假设 ProcessSuccessResult
是您有权访问并能够编辑的 class?如果是这样,您应该能够向其添加一个接口,该接口将包含您需要的方法,以便您稍后可以对其进行处理。
一旦你定义了它,你应该能够如下创建你的假对象,其中 IProcessSuccessResult
将是你的接口的假实现,由 FakeItEasy 提供:
var processSuccessResult = A.Fake<IProcessSuccessResult>();
现在您应该能够使用 A.CallTo(...)
向该假对象添加逻辑。
当然,这意味着 class ProcessSuccessResult
的真正实现是 不 包含或通过变量 processSuccessResult
调用.如果需要其中的一部分,那么您可以尝试:
- 添加类似的逻辑,或者使用 FakeItEasy 的设置代码从假对象调用它(尽管这可能会变得过于复杂),或者:
- 添加一个单独的变量以包含真实 class 的实例(即两个变量分别为
fakeProcessSuccessResult
和 processSuccessResult
),并使用单独的测试来测试您的不同方面class 及其用法。
如果可能的话,我会推荐后者。
我希望这足够清楚,并且对您有用。我知道有时候要找到测试此类事情的最佳策略可能会非常复杂。
我目前正在为我添加到 ASP.NET 项目中的一些新功能做一些单元测试(不,这不是试驾设计)。我们使用 NHibernate 框架并使用 UnitTest Mock-ing 库 FakeItEasy
.
我有以下 class & 我想测试的方法:
public class Round
{
public static Round Create(List<Company> activeCompanies, Period period,
BusinessUser user, BusinessUser systemUser,
ISession session, IEntityQuery entityQuery,
RoundProcessBuilder processBuilder)
{
var round = new Round
{
Processes = new List<Process>();
Period = period,
CreationDate = DateTime.Now,
CreatedBy = user
};
// Save the Round in the DB so we can use it's Id in the Processes:
session.Save(round);
foreach (var company in activeCompanies)
{
var companyData = session.Get<CompanyData>(company.Id);
var processResult =
roundProcessBuilder.Build(
systemUser,
new CreateRoundProcessData(company, round, companyData),
entityQuery,
session);
processResult.HandleProcess(process =>
{
// serviceBus can stay null
process.Create(systemUser, DateTime.Now, session, null);
// No need to save the session here. If something went
// wrong we don't want halve of the processes being saved
round.Processes.Add(process);
// It's all or nothing
});
}
return round;
}
}
我主要想测试的是:当我使用这个Round#Create
方法时,假设有 100 个活跃的公司,它应该创建 100 个进程,并且每个进程应该包含 RoundId
.
到目前为止,这是我的单元测试:
[TestFixture]
public class RoundTest
{
private BusinessUser _systemUser;
private DateTime _creationDateRound1;
private List<Company> _activeCompanies;
private RoundProcessBuilder _roundProcessBuilder;
private ISession _session;
[SetUp]
public void Setup()
{
_creationDateRound1 = new DateTime(2015, 10, 5);
_systemUser = TestHelper.CreateBusinessUser(Role.Create("systemuser", "test",
Int32.MaxValue));
_activeCompanies = new List<Company>
{
TestHelper.CreateCompany();
};
_roundProcessBuilder = A.Fake<RoundProcessBuilder>();
_session = A.Fake<ISession>();
}
[Test]
public void TestCreateRoundWithoutPreviousRound()
{
var fakeExpectedRound = Round.Create(_activeCompanies, DateTime.Now.ToPeriod(),
_systemUser, _systemUser, _session, null, _roundProcessBuilder);
var fakeExpectedRoundData = RoundProcessData.Create(TestHelper.CreateCompany(),
fakeExpectedRound, new CompanyData());
var fakeExpectedProcess = new Process(_systemUser, null, "processName", null,
fakeExpectedRoundData, "controllerName", null);
var processSuccessResult = new ProcessSuccessResult(fakeExpectedProcess);
A.CallTo(() => _roundProcessBuilder.Build(null, null, null, null))
.WithAnyArguments()
.Returns(processSuccessResult);
A.CallTo(() => processSuccessResult.HandleProcess(A<Action<Process>>.Ignored))
.Invokes((Action<Process> action) => action(fakeExpectedProcess));
var round = Round.Create(_activeCompanies, _ceationDateRound1.ToPeriod(),
_systemUser, _systemUser, _session, null, _roundProcessBuilder);
Assert.AreEqual(_activeCompanies.Count, round.Processes.Count, "Number of processes");
Assert.AreEqual(round.Period.Quarter, Math.Ceiling(_creationDateRound1.Month / 3.0m), "Quarter");
Assert.AreEqual(round.Period.Year, round.Year, "Year");
// Test if each of the processes knows the RoundId, have the proper state,
// and are assigned to the systemuser
//foreach (var process in round.Processes)
//{
// var roundProcessData = process.ProcessData as RoundProcessData;
// Assert.IsNotNull(roundProcessData, "All processes should have RoundProcessData-objects as their data-object");
// Assert.AreEqual(roundProcessData.Round.Id, round.Id, "RoundId");
// Assert.AreEqual(process.Phase.State, PhaseState.Start, "Process state should be Start");
// Assert.AreEqual(process.AssignedTo, _systemUser, "AssignedTo should be systemuser");
//}
}
... // More tests
}
我的问题出在下面的代码上:
A.CallTo(() => processSuccessResult.HandleProcess(A<Action<Process>>.Ignored))
.Invokes((Action<Process> action) => action(fakeExpectedProcess));
它给出一个“The specified object is not recognized as a fake object.
”错误。
我有这部分代码的原因是因为没有它下面部分的 process
是空的:
processResult.HandleProcess(process => // <- this was null
{
process.Create(systemUser, DateTime.Now, session, null);
round.Processes.Add(process);
});
PS:我在我的 UnitTest 中取消注释 foreach 并进行额外检查,因为当我模拟 process
本身时它很可能毫无用处。我的主要测试是是否创建了进程并且根据给定的活跃公司添加到列表中。
您的问题似乎是您正试图将 "fake" 逻辑添加到一个实际上不是假的对象:
// You create this as an instance of ProcessSuccessResult:
var processSuccessResult = new ProcessSuccessResult(fakeExpectedProcess);
...然后继续尝试在此处添加条件:
A.CallTo(() =>
processSuccessResult
.HandleProcess(A<Action<Process>>.Ignored))
.Invokes((Action<Process> action) => action(fakeExpectedProcess));
为了完成最后一点,变量 processSuccessResult
需要是接口的假实例,以便 FakeItEasy 可以使用它,并应用您想要的逻辑。
我假设 ProcessSuccessResult
是您有权访问并能够编辑的 class?如果是这样,您应该能够向其添加一个接口,该接口将包含您需要的方法,以便您稍后可以对其进行处理。
一旦你定义了它,你应该能够如下创建你的假对象,其中 IProcessSuccessResult
将是你的接口的假实现,由 FakeItEasy 提供:
var processSuccessResult = A.Fake<IProcessSuccessResult>();
现在您应该能够使用 A.CallTo(...)
向该假对象添加逻辑。
当然,这意味着 class ProcessSuccessResult
的真正实现是 不 包含或通过变量 processSuccessResult
调用.如果需要其中的一部分,那么您可以尝试:
- 添加类似的逻辑,或者使用 FakeItEasy 的设置代码从假对象调用它(尽管这可能会变得过于复杂),或者:
- 添加一个单独的变量以包含真实 class 的实例(即两个变量分别为
fakeProcessSuccessResult
和processSuccessResult
),并使用单独的测试来测试您的不同方面class 及其用法。
如果可能的话,我会推荐后者。
我希望这足够清楚,并且对您有用。我知道有时候要找到测试此类事情的最佳策略可能会非常复杂。