Implement a solution that uses Reflection to create a class automatically

[Rockylars]

Probably calling it something like "ReFaker", "Reflector" or "Mirror".

What we need are 3 things

• Method call bindings to automatically know what methods are available and being able to quickly globally refactor them.
• Binding an interface to a new instance and being able to set returns for the methods inside of it.
• Adding the Faker class (or as a trait) for easy function calls.

Maybe an inspiration could be Mockery since it has most of those features, though again, I simply dislike the loose method syntax.

[Rockylars]

There is actually a little more to it. There's certain argument objects that can't be captured in their entirety due to magic methods inside acting up or due to it being an overload of data. There's also those with no argument that still need to record their calls being made. This is a lesser need and lesser issue, we just need to account for it in the future.

[Rockylars]

Been working on it and so far I've noticed that I'm simply rebuilding what Mocker is already doing. Maybe i could bring a new version of it to the table, but so far I don't really see what I'm adding. Sure the fact that you gotta keep creating classes is a hassle, but I'd say that redefining method capture configs each time for those outliers that need to do it, though most are fine not having it is still more effort.

I'd say that there's definitely something here, but so far I'm not seeing the benefit aside of simply not creating the class. I'd still say that's a valid option though, so I will continue to look into it, but maybe that should just be a case of "Use Mocker" or making a separate project called "Mirror" to make these faked reflections.

[Rockylars]

It does have a difference, Mocker has a difficult way of writing it. With this class, you can define the responses first and then confirm the arguments. What this allows you to do is that any service that does not modify the record sent in can be faked and thus reduces test doubling. One feature we could even add is to add a function variant which runs the function on the arguments sent in. This different way of mocking is thus empowered by replicating Mocker's copying method.

[Rockylars]

I'd say that this feature would help, but now if you have a capturing method that's different than just grabbing all the arguments, you'd need to be able to define it once and then forget it while also allowing it to be overwritten on the spot in a test.

A solution for this is to have a config class that binds an anonymous function with how it should save the arguments and with a per test option to also define it.

[Rockylars]

It needs to either manage or reject:

• class
• class with constructor
• abstract class
• trait
• abstract class with abstract methods
• final class
• anonymous class
• interface
• object
• class already containing Faker
• class with same method names (maybe rename ours with two underscores in front?)