You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What this allows me to do when testing classes that use dependency injection is to create a set of "happy" default behaviors for all of the mockks injected into my class under test.
IE, I can create my class under test like this.
val fooBarService = makeSubject()
val result = fooBarService.getFooBar()
assertEquals("foo bar dog", result)
If I want to swap out functionality, I can do so like this
val fooBarService = makeSubject(fooService_getFoo = returns("cool"))
val result = fooBarService.getFooBar()
assertEquals("cool bar dog", result)
I find that this makes it very easy to test permutations of service failures / alternate responses in a way that is immutable with no chance of leaking into other test cases, which I see happen fairly often in tests that utilize beforeEachTest type lifecycle hooks /
mutation of mockks to achieve the same result.
New Syntax
Currently, I am using the following code for everything above, naming is totally up for discussion
this is honestly the meat of the whole thing, it allows you to easily decouple the every {} from the answer as a function argument.
Most importantly, it doesn't obfuscate anything inside of MockKStubScope
This is just a type alias that prevents you from needing to write MockKStubScope<T, T>.() -> Unit over and over again.
returns
fun <T> returns(value:T): Stub<T> = { returns(value) }
syntactic sugar so you don't need to = { returns(value) }
answers
fun <T> answers(answerScope:MockKAnswerScope<T, T>.(Call) ->T): Stub<T> = { answers(answerScope) }
syntactic sugar so you don't need to = { answers { firstArg() } }
Plugin
I'm also working on a plugin for my IDE that will find all functions used by dependencies for a given class and generate the boilerplate you see above.
IE, if those three stubs were used inside of fooBarService, my plugin would allow you to generate
This removes a lot of ceremony for testing classes that leverage DI
Question
Does this seem like something that would be beneficial to exist within the mockk ecosystem? I'd be happy to do or help with the implementation if this seems useful.
The text was updated successfully, but these errors were encountered:
Background / Proposal
Recently, I've started using a new pattern to create my mockks, it looks something like this ( I'll explain new syntax at the end )
What this allows me to do when testing classes that use dependency injection is to create a set of "happy" default behaviors for all of the mockks injected into my class under test.
IE, I can create my class under test like this.
If I want to swap out functionality, I can do so like this
I find that this makes it very easy to test permutations of service failures / alternate responses in a way that is immutable with no chance of leaking into other test cases, which I see happen fairly often in tests that utilize
beforeEachTest
type lifecycle hooks /mutation of mockks to achieve the same result.
New Syntax
Currently, I am using the following code for everything above, naming is totally up for discussion
calls
this is honestly the meat of the whole thing, it allows you to easily decouple the
every {}
from the answer as a function argument.Most importantly, it doesn't obfuscate anything inside of MockKStubScope
IE, without the syntax sugar
Stub
This is just a type alias that prevents you from needing to write
MockKStubScope<T, T>.() -> Unit
over and over again.returns
syntactic sugar so you don't need to
= { returns(value) }
answers
syntactic sugar so you don't need to
= { answers { firstArg() } }
Plugin
I'm also working on a plugin for my IDE that will find all functions used by dependencies for a given class and generate the boilerplate you see above.
IE, if those three stubs were used inside of fooBarService, my plugin would allow you to generate
This removes a lot of ceremony for testing classes that leverage DI
Question
Does this seem like something that would be beneficial to exist within the mockk ecosystem? I'd be happy to do or help with the implementation if this seems useful.
The text was updated successfully, but these errors were encountered: