Values from already mocked methods are not taken into account when initializing a static constructor from the Telerik.JustMock.PrivateAccessor class.
Here is an example: PrivateAccessor.ForType(typeof(Foo)).SetField("someStringField", "stringvalue");
A workaround is to call the: Mock.Intercept(typeof(Foo)); before calling the PrivateAccessor.
Let's have the following class and unit test:
public delegate Task<int> SomeDelegate();
private async Task<int> DoSomeStuff()
{
await Task.Delay(100);
return 1;
}
}
// Assert
Mock.Assert(next);
Assert.AreEqual(3, sum);
}
JustMock public API lacks of convenient way to assert that particular task has been awaited. Potential workaround involves some "insider knowledge" that awaiting a Task internally results in a calls to some of its members.
Hi I have encountered what I think is a bug.
I would expected the following unit test to pass. It does not.
The example is distilled from a more complex case.
Is it not supported to have other threads create mocks?
[Fact]
public async Task Fails()
{
var iTask = Task.Run(() => Mock.Create<I>());
var i = await iTask;
EA expectedArgs = new EA();
EA receivedArgs = null;
i.Done += (sender, ea) => receivedArgs = ea;
i.Raise(x => x.Done += null, expectedArgs);
Assert.Equal(expectedArgs, receivedArgs);
}
public class EA : EventArgs
{
}
public interface I
{
event EventHandler<EA> Done;
}
Types that implement ISerializable can't be mocked anymore with the 2019.1.115.2 version resulting in System.ArgumentException. The issue is a regression compared to older versions of JustMock.
Example of such type is System.Reflection.Assembly.
Creating a share link with Visual Studio Live Share does not work if you have the JustMock profiler enabled. We specifically have to disable the JustMock profiler in order for VS Live Share to create sharing links. This has been reproduced by several different members of our team. Could this please be looked into? Thanks!
Currently, there is no out of the box support for passing "out" and "ref" parameters for nonpublic API.
If there are more that one mock objects existing in the test, Mock.Assert wrongly succeeds while evaluating arrangements for each mock, but not the very first one. This is a regression compared to an older version from 2012. The following sample demonstrates the case: public interface IFoo { void Bar(); } [TestClass] public class UnitTest1 { [TestMethod] public void TestMethod1() { var bar = Mock.Create<IFoo>(); Mock.Arrange(() => bar.Bar()).OccursOnce(); var foo = Mock.Create<IFoo>(); Mock.Arrange(() => foo.Bar()).OccursOnce(); Mock.Assert(foo); // Would wrongly succeed Mock.Assert(bar); // Would fail as expected } }
A class property get wrongly mocked when used as parameter for arranging other class methods. The following sample demonstrates the scenario: class Foo { public string Prop{ get; set; } public void Bar(string val) { } } [TestMethod] public void Sample() { var sut = Mock.Create<Foo>(Behavior.CallOriginal); Mock.Arrange(() => sut.Bar(sut.Prop)).DoNothing(); }