Enforcement of adherence to original typespecs on stubbed functions?

[wanderanimrod]

Enforcement of adherence to original typespecs on stubbed functions?

[wanderanimrod]

No it's okay. I just wanted to knw what is more pressing for you so I start with that. I'll look at the Typespecs and update this issue with progress as I go.

Thanks again for your contribution.

[wanderanimrod]

Hi @facto,

I don't think we should make the library read typespecs and force mocks to adhere to them. Elixir's Behaviours do something very similar to what you are trying to achieve. I would prefer we go with allowing mocks to be defined based on behaviours. I think that might be a cleaner way to get you to where you want to go.

Am I understanding you right?

[joshrieken]

Thanks, @wanderanimrod.

I think that would work great when generating mocks for modules that already implement behaviours. But not all modules do, so enforcing adherence to existing typespecs, if any, would also be useful I think.

[wanderanimrod]

Looks like examining typespecs at runtime is possible. I'll look into this and see what can be done.

If you had to chose between Behaviours and Typespecs support, which one would you do first?

[joshrieken]

@wanderanimrod Hmm... Either would be fine. Personally, I'd probably utilize the typespecs more. I'm happy to try my hand at the typespecs if you want to split the work.

[wanderanimrod]

@facto ,

Whereas you can inspect typespecs attached to a function using Kernel.Typespec.beam_specs/1, you cannot force functions to completely adhere to these specs. Specifically, you cannot enforce that a function's arguments or its return value are of a certain type precisely because type information is not available at compile time in elixir. Tools like Dialyzer have a lot of elaborate tricks but still cannot catch all type-related errors at compile time. That's is why they resort to "optimisitic type checking".

ElixirMock currently does not allow functions that don't match original module functions by name and arity. That takes care of the arity aspect of type specs. It deosn't take care of the type aspect for reasons explained above.

I feel therefore that the safety measures already present are as far as we can go in a dynamically typed environment.

Let me know if this is clear. I'll close this issue for now.

[joshrieken]

Yep, makes sense. Thanks.