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();
}

Docker is a container acting like an isolated environment. Research how the JustMock profiler can be registered into such container.
Hosted VSTS should work on the same principle. Research how the registry could be accessed through VSTS extension or other tools.

Currently JustMock does not support mocking non-public generic methods. There are couple of possible workarounds but the need for proper implementation for mocking the language feature is still required.

Implement support for code coverage in the JustMock VSTest v.2 Azure Pipeline task similar to the code coverage option available in VS Test task.

The JustMock tests are failing when the "Test platform version" option in the JustMock VSTest v.2 task is set to value "Installed by Tools Installer".

Basically calling Mock.Reset at the end of the method is not safe.
It seems like the the way JustMock iterates over an IEnumerable is not correct.
Log:
2019-01-25T09:23:53.9254819Z Warning: System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
2019-01-25T09:23:53.9254819Z    at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
2019-01-25T09:23:53.9254819Z    at System.Collections.Generic.Dictionary`2.Enumerator.MoveNext()
2019-01-25T09:23:53.9254819Z    at Telerik.JustMock.Core.MocksRepository.CopyConfigurationFromParent()
2019-01-25T09:23:53.9254819Z    at Telerik.JustMock.Core.MocksRepository.Reset()
2019-01-25T09:23:53.9254819Z    at Telerik.JustMock.Core.Context.HierarchicalTestFrameworkContextResolver.RepositoryOperationsStrongRef.RetireRepository(Object key, MocksRepository repo)
2019-01-25T09:23:53.9254819Z    at Telerik.JustMock.Core.Context.HierarchicalTestFrameworkContextResolver.FindRepositoryInOps(RepositoryOperationsBase entryOps, Object entryKey)
2019-01-25T09:23:53.9254819Z    at Telerik.JustMock.Core.Context.HierarchicalTestFrameworkContextResolver.RetireRepository()
2019-01-25T09:23:53.9254819Z    at Telerik.JustMock.Core.Context.MockingContext.RetireRepository()
2019-01-25T09:23:53.9254819Z    at Telerik.JustMock.Core.ProfilerInterceptor.GuardInternal(Action guardedAction)
2019-01-25T09:23:53.9254819Z    at Sap.Tests.<MyTests_DoAsync_ReturnTrue>d__26.MoveNext() in E:\Builds\_work\9\s\Tests\MyTests.cs:line 476
2019-01-25T09:23:53.9254819Z    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
2019-01-25T09:23:53.9254819Z    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
2019-01-25T09:23:53.9410972Z    at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
2019-01-25T09:23:53.9410972Z    at System.Threading.ThreadPoolWorkQueue.Dispatch()
2019-01-25T09:23:53.9410972Z    at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
2019-01-25T09:23:53.9410972Z    at System.Collections.Generic.Dictionary`2.Enumerator.MoveNext()
2019-01-25T09:23:53.9410972Z    at Telerik.JustMock.Core.MocksRepository.CopyConfigurationFromParent()
2019-01-25T09:23:53.9410972Z    at Telerik.JustMock.Core.MocksRepository.Reset()
2019-01-25T09:23:53.9410972Z    at Telerik.JustMock.Core.Context.HierarchicalTestFrameworkContextResolver.RepositoryOperationsStrongRef.RetireRepository(Object key, MocksRepository repo)
2019-01-25T09:23:53.9410972Z    at Telerik.JustMock.Core.Context.HierarchicalTestFrameworkContextResolver.FindRepositoryInOps(RepositoryOperationsBase entryOps, Object entryKey)
2019-01-25T09:23:53.9410972Z    at Telerik.JustMock.Core.Context.HierarchicalTestFrameworkContextResolver.RetireRepository()
2019-01-25T09:23:53.9410972Z    at Telerik.JustMock.Core.Context.MockingContext.RetireRepository()
2019-01-25T09:23:53.9410972Z    at Telerik.JustMock.Core.ProfilerInterceptor.GuardInternal(Action guardedAction)
2019-01-25T09:23:53.9410972Z    at Sap.Tests.<MyTests_DoAsync_ReturnTrue>d__26.MoveNext() in E:\Builds\_work\9\s\Tests\MyTests.cs:line 476
2019-01-25T09:23:53.9410972Z    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
2019-01-25T09:23:53.9410972Z    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
2019-01-25T09:23:53.9410972Z    at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
2019-01-25T09:23:53.9410972Z    at System.Threading.ThreadPoolWorkQueue.Dispatch()

Mocking an async calls alse triggers hidden mocking of the return type. Depending of the type it might cause unexpected behavior or exception.

2019.R1 JustMock Test project templates need to be updated to support .Net Core, currently they are targeting just .Net Framework (see attached screen shot).

Implement support for future mocking of non-public classes.

Implement support for future mocking of public class with non-public arguments.
Such example is the future mocking of the class Timer with a private callback.

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?

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. 

A simple WinForms application crashes on start when JustMock(2019.1.115.2) profiler is enabled.

Steps to reproduce:
1. Create a new WinForms Application.
2. Start the application. In Debug it is most visible. 
3. After the application is started move the mouse in the middle of the application. The exact location is not important.
4. A FieldAccessExceptionis is thrown.



Temporary workaround: disable the JustMock Profiler from the JustMock menu while developing the application and enable it while running the tests.
A fix can be expected with the next official release. You can follow this item in order to receive status updates.

The main point behind this request is to add new command line option to JustMockRunner in order to enable profiler without need for being registered, more details about this feature can be found on MSDN at https://msdn.microsoft.com/en-us/library/ee471451(v=vs.100).aspx

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
    }
}

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!

When using Mock.CreateLike<> we've found that trying to directly mock anything lower than two layers down on a concrete class (e.g. x => x.Layer1.Layer2.Property == "test") throws a NullReferenceException unless the profiler is enabled. It wasn't clear in the exception or the documentation relating to this method that the real issue was the profiler being disabled, and only by trial and error did we find the solution.

If I define a fluent API, I might have an interface such as this:

public interface IRegistrar { 

IRegistrar UsingThis(object someThing);

IRegistrar UsingThat<TThatThing>() }

If I create a mock of this using the default Behaviour.RecursiveLoose and make no arrangements, calls to the methods will return new mocks of the type, rather than the same instance that was called. 

It would be nice to have a behaviour type that can return the same instance (in this case the mocked instance) without having to define a stub for each method call.

My code under test might look like:

IRegistrar reg;

reg

  .UsingThis(new object())

  .UsingThat<int>();

Currently, a test on the second call will fail if written against the mock assigned to 'reg'.

this nuts, forcing me to answer a dialog for JustMock and JustTrace to turn off sending usage to Telerik.  Very poor UX.  Stop doing this.