Add ability to mock method called with specific argument value.

[justin-lyon]

This is quite a nice feature in Mockito, which has a similar grammar to to UniversalMocker (not sure if that was intentional or not)

But essentially allowing me to return different values (or throw different exceptions) by both method Name AND the argument values passed into the method.

This feature is required in order to test some recursive logic I've got that recursively calls a Custom Metadata's Parent until it has crawled to the top of the parent child hierarchy.

https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#stubbing

Sample method that this feature would be great for testing with

// How a Sample Test might Look
mdtServiceStub.when('getInstance')
  .with('GrandParent')
  .thenReturn(new Config__mdt(DeveloperName = 'GrandParent')); 
mdtServiceStub.when('getInstance')
  .with('Parent')
  .thenReturn(new Config__mdt(DeveloperName = 'Parent', ParentName__c = 'GrandParent'));
mdtServiceStub.when('getInstance')
  .with('Child')
  .thenReturn(new Config__mdt(DeveloperName = 'Child', ParentName__c = 'Parent'));

Caller sut = new Caller();
List<Config__mdt> configs = sut.crawlConfig('Child');

// ...Assert that the List<Config__mdt> has all three items after recursively calling getInstance with different mdt Names

// Sample Unit
public List<Config__mdt> crawlConfig(final String name) {
  List<Config__mdt> configMdts = new List<Config__mdt>();
  Config__mdt mdt = mdtService.getInstance(name);

  if (String.isNotBlank(mdt.ParentName__c)) {
    // Crawl up the Parents
    List<Config__mdt> parents = crawlConfig(name);
    configMdts.addAll(parents);
  }

  // Add children last
  configMdts.add(mdt);

  return configMdts;
}

// --> End Result is a List sorted in hierarchical order, Parent to Child.

[infocynic]

This would be extremely helpful for some of our tests as well. For example, I have a service that calls a function in a loop and I need to vary the outcomes within the scope of a single test to validate things like "one true and two false" [and refactoring the service is not really on the table right now].

I would slightly modify @justin-lyon 's suggestion and have the .with() method require specifying something like a Map<string,Object> to allow matching exact parameters with multiple arguments. Though I would be happy to take a 1.0 version that only worked for single-primitive-argument functions, as those generally are the cases I need this for.

[Thieveryshoe]

I agree with @infocynic above, the .with() call should accept a collection of some sort. I believe our homegrown testing framework accepts a List<Object>. Whichever way works best here is fine with me. I just wanted to throw my two cents in for the additional change.

[justin-lyon]

maybe .with could be overloaded. Anyway, I trust @surajp to come up with something that fits the spirit of the request - and probably come up with an implementation better than I could recommend anyhow.

[surajp]

Sorry I've been falling behind on keeping up with this repo. I've had a couple of things in flight now and plan on getting to it within the next week. When building this library, I had left out mocking with specific argument values on purpose to force tests to be as dumb as possible. The more logic you add to mocking, the higher the chances you could have bugs in your logic that lead to false negatives. The limitation is even called out in the Notes That being said, I understand and can appreciate the need for this feature for scenarios like recursion.

Although accepting a Map<String,Object> like what @infocynic said seems to be the most straightforward approach in my opinion, I would like to mull over the possibility of accepting one argument at a time for 2 reasons:

• Make your mocking logic more obvious at a glance
• Allow the ability to mock with partial arguments i.e. if your method takes 2 arguments, only specify 1 for conditional mocking

So something like

mdtServiceStub.when('getInstance')
  .with('name','Child')
 .and('anotherParam','anotherValue')
  .thenReturn(new Config__mdt(DeveloperName = 'Child', ParentName__c = 'Parent'));

The downside to this approach is that now you're tying your tests to your method param names, which seems like an unnecessary coupling.

[Thieveryshoe]

I'm on mobile at the moment (on vacation), but to your point of only specifying one argument of a function that takes two arguments...

Over in the .net world and Moq testing framework there is the concept of Any. For instance, if your signature looks like public void foo(String bar, Integer bazz) and you only wanted to specify the integer argument, you could write something like this:

mockThing.Setup(x => x.foo(It.IsAny<String>(), 4))

Ignore the lambda stuff, just trying to show the technique that Moq uses. This checks for any string and specifically, 4.

Thanks for taking feedback @surajp!

[infocynic]

yeah I think this could work. just chain `and` as many times as you want, any parameter that isn't specified via with/and is ignored. if you invoke with a value that doesn't match a setup (given that the only configured mocks use `with`) then I would expect an exception or return null, whatever is consistent with calling a method you didn't stub currently.

…

On Mon, May 1, 2023, 10:22 AM Suraj Pillai ***@***.***> wrote: Sorry I've been falling behind on keeping up with this repo. I've had a couple of things in flight now and plan on getting to it within the next week. When building this library, I had left out mocking with specific argument values on purpose to force tests to be as dumb as possible. The more logic you add to mocking, the higher the chances you could have bugs in your logic that lead to false negatives. The limitation is even called out in the Notes <https://github.com/surajp/universalmock#notes> That being said, I understand and can appreciate the need for this feature for scenarios like recursion. Although accepting a Map<String,Object> like what @infocynic <https://github.com/infocynic> said seems to be the most straightforward approach in my opinion, I would like to mull over the possibility of accepting one argument at a time for 2 reasons: - Make your mocking logic more obvious at a glance - Allow the ability to mock with partial arguments i.e. if your method takes 2 arguments, only specify 1 for conditional mocking So something like mdtServiceStub.when('getInstance') .with('name','Child') .and('anotherParam','anotherValue') .thenReturn(new Config__mdt(DeveloperName = 'Child', ParentName__c = 'Parent'));``` — Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGNU2BGNJ7YYN6D5LG7BL3XD7BJRANCNFSM6AAAAAAXMCXZZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>