what do you all consider the best practice when it comes to typing/naming mockks and why? (not reall...

# mockk

[Michael de Kaste]

what do you all consider the best practice when it comes to typing/naming mockks and why? (not really mockk specific question but its something we keep coming across in our team)

1. val namingFactory: NamingFactory = mockk()
2. val namingFactory = mockk<NamingFactory>()

[Mattia Tommasone]

i don’t think it makes a real difference, the IDE will recognize your namingFactory to be a NamingFactory in either case.
I couldn’t find anything about it in the kotlin style guide, so i really think that’s up to you and your team

[Klitos Kyriacou]

I would tend to call it mockNamingFactory though.

[thanksforallthefish]

I like option two, and I think kotlin prefers two too

just try to extract a mockk and idea does two, eg

val helper = Helper(mockk())

now try to extract mockk() to a variable, using idea refactoring and it becomes

val whatever = mockk<Whatever>()

I would do the same manually if not to keep style consistent and not having to “fix” the style manually

[Klitos Kyriacou]

But that's option 2.

[thanksforallthefish]

indeed, I am consistent also with typos 😄

[Michael de Kaste]

@thanksforallthefish I tend to agree, but generating implementations of interfaces always makes variables like so:

override val someValue: Int
    get() = TODO()

[Michael de Kaste]

so trusting how intellij does it might not be a good argument (for me against my colleagues :P)

[Ondřej Šimon]

Personally I use the first approach, also suffixing the mocked instance with Mock, e.g. someServiceMock.

[Tom Yuval]

For what it’s worth, note the difference between a member property and a local variable:
• For a member property, it seems to be customary (though not obligatory, and not always the case, even in the standard library) to specify the type explicitly (which explains the example of implementing an interface above).
• For a local variable, it seems to be customary not to specify the type explicitly lacking a good reason to do so.
Personally, I would go for 1️⃣ if it’s a member property and for 2️⃣ if it’s a local variable.

[Tom Yuval]

(And I think namingFactory is perfectly fine, no need to specify it’s a mock explicitly in the name unless the context requires disambiguating between two naming factories one of which is a mock and one isn’t.)

[igor.wojda]

2nd is cool, but I find 1st is easier to write, so I go with 1st