You have to mock whatever is inside the inline cal...
# mockk
l
You have to mock whatever is inside the inline call
v
Oh dear. There is a lot of code in that function... And it's the code inside that I want to test.
l
What do you mean?
The thing is: the inline modifier makes the function not exist in bytecode. It only exists in the source code
Because everything inside it is replaced at compile time
If the function is big, I'd suggest extracting every bit you can out of it
And if inline is not really necessary, remove it alltogether
v
I have to say, this is beyond me. Kotlin encourages all these inline functions and lambdas, but testing code which uses them hurts my brain.
l
I suspect that perhaps you're misusing lambdas and inline functions
They're easy to test
But you should test what they do, not how they do
If you test that every call is called and that it calls the static methods in that exact order, everything will turn into hard to test!
I use and abuse Lambdas and Inlines at #kotlintest and at my work, and I never had a problem with them
Perhaps you're placing too many calls inside the inline functions? Perhaps you're trying to mock a part of code that should be executed, not mocked?
I usually only mock external dependencies, not lambdas or inlines
v
All I want to do is mock my way around reading a directory of files...
Copy code
project.dirs.sources.walk().forEachIndexed { index, mdFile ->
	val inputStream = mdFile.inputStream()
	val document = parseMarkdown(inputStream)
}
l
In this cases I usually have that reading in a class or function, such as
readInputStream(file)
And I mock that function
And it's not inlined, as that won't use any of inline features
I will never mock the
forEachIndexed
function
v
OK, I've got a lot to learn it seems. Kotlin makes it very easy to just through yourself in, but working alone also means it's easy to pick up bad habits.
Thanks for your time 🙂
291 Views