To reproduce this:
using Rocks;
public interface IHaveNamingConflicts
{
// If there are any other variables that Rocks create, include them as parameters.
int Foo(string methodHandlers, string methodHandler, string result);
}
public static class Test
{
public static void Run() => Rock.Create<IHaveNamingConflicts>();
}
The parameter names conflict with variables Rocks generates in the mock. Need to ensure the generated names do not conflict with any parameters. Would be good to generalize this in case other variables are created in the mock in the future.
I think this would also have to be done for the self parameter used in extension methods, as well as the constructorProperties named used in Instance() for required and init properties.
To reproduce this:
The parameter names conflict with variables Rocks generates in the mock. Need to ensure the generated names do not conflict with any parameters. Would be good to generalize this in case other variables are created in the mock in the future.
I think this would also have to be done for the
selfparameter used in extension methods, as well as theconstructorPropertiesnamed used inInstance()forrequiredandinitproperties.