Ability to assert what arguments a method was called with

[littletof]

Summary

What: Now, that there are stubs and mocks, it would be great if we could check with what argument they were called with.

Why: It helps to check correct behaviour and it exists in other frameworks too. eg: Jasmine's toHaveBeenCalledWith

Acceptance Criteria

• Ability to check and test arguments of a previously called stub and/or mock method

Example Pseudo Code (for implementation)

Will have to figure out where it should be accessed from.

Maybe mock.calls.methodToTest should return an object with { count: number, lastArgs: any[]}, but it would change current signature.

Or maybe mock.calls.args.methodToTest but than if there is a method named args it would cause problems

Rhum.testPlan("My Plan", () => {
  Rhum.testSuite("My Suite", () => {
    Rhum.testCase("My Test Case", () => {
      const mock = Rhum
        .mock(Server)
        .withConstructorArgs("arg1", "arg2", "arg3") // this call optional
        .create();

      mock.methodToTest("arg1", 15, null);
      Rhum.asserts.assertEquals(mock.calls.methodToTest.count, 1);
      Rhum.asserts.assertEquals(mock.calls.methodToTest.lastArgs, ["arg1", 15, null]);
    });
  });
});

[crookse]

Sounds good to me! I like the first option but right now it doesn’t seem to fit under calls to me. Going to think about it. @ebebbington @Guergeiro @saragee3 thoughts?

[ebebbington]

I think it makes sense to be honest, it's another way for assertions, and i think it'll be a good feature dev might want to use

I too like the first option

[Guergeiro]

I approve any of the options. Will any of the implementations change the API of the function? Remember that we already released v1, so we can't change the API. Changing the signature to add fields is okay.

[crookse]

I think this is how we should go about it. It won't break the API. However, it does mean we'll have a list of reserved properties that a mock will have and we'll need to document that. In the Sockets repo, we have a list of reserved events, so I'm ok with having a list of reserved properties.

const mock = Rhum
    .mock(Server)
    .withConstructorArgs("arg1", "arg2", "arg3")
    .create();
// constructor_args is reserved
Rhum.asserts.assertEquals(mock.constructor_args.methodToTest, ["arg1", "arg2", "arg3"]);

mock.methodToTest("arg1", "arg2", "arg3");
// function_args is reserved
Rhum.asserts.assertEquals(mock.function_args.methodToTest, ["arg1", "arg2", "arg3"]);
// calls is reserved
Rhum.asserts.assertEquals(mock.calls.methodToTest, 1);

[littletof]

@crookse I like this solution.

Two things:

• does constructor_args need .methodToTest? Shouldn't is be just constructor_args?
• for function_args I would somehow emphasise that it returns the last calls arguments like mock.lastcall_args.methodToTest. But function_args could be fine too.

[crookse]

1. oops. copypasta. i mean mock.constrcutor_args
2. I agree. It's more explicit and makes more sense to me. last_args works.

[crookse]

Using wasLastCalledWith(). see PR #77