4 ms·

Wow, there's a lot of anger in some of these posts. I've been using Mockito for about 4 years, all in Kotlin. I always found it to be "plenty good" for like 99

Wow, there's a lot of anger in some of these posts. I've been using Mockito for about 4 years, all in Kotlin. I always found it to be "plenty good" for like 99% of the cases I needed it; and things more complicated or confusing or messy were usually my fault (poor separation of concerns, etc). I regularly found it quite helpful in both its spy() and mock() functionality. I never found it meaningfully more or less useful than MockK, though I have heard MockK is the "one that's better for Kotlin". It's mostly just vocabulary changes for me, the user. I'm going to have to monitor Mockito's future and see if I'll need to swap to MockK at some point if Mockito becomes unmaintained.

emodendroket 10mo ago
At the end of the day I think there's nothing wrong with the tool itself. The problem is that mocking and spies make it easy to not bother properly isolating the effects of a function for testing and then you end up having a test where 95% of it is setting up an elaborate array of mocks to create the condition you wish to test, which are completely incomprehensible to the next person trying to read it.
- lisbbb 10mo ago
  I used it mainly because the code I inherited was untestable as written. I made it testable via those methods. Then it got refactored.
  - emodendroket 10mo ago
    Well sure you sometimes haven’t got much choice. But I’m talking about people write new code this way
gerdesj 10mo ago
"Wow, there's a lot of anger in some of these posts." If I was OP I'd retire happy knowing that a very thankless job is well done! Given what it does: the more outrage the better. Projects like Mockito call out the lazy and indolent for whom they are and the hissing and spitting in return can simply be laughed at. 10 years this bloke has given his time and effort to help people. He states: nearly a third of his life. I'll raise a glass and say "was hale" or perhaps wassail as an Englander might.
WD-42 10mo ago
Is it anger? The agent thing maybe. The other two points seem to boil down to: 1. Kotlin is a hack and 2. Rust is more fun. Pretty understandable why one would simply want to move on to greener pastures.
- vips7L 10mo ago
  I'm not sure Kotlin is a hack, but it's growth is directly related to Java not being able to deliver on simple features that would help the day to day lives of developers. So I also can't blame anyone for moving on from the language. I get frustrated with it all the time, especially when Kotlin shows that some feature could work perfectly fine. Here are some examples that have hit the graveyard: It's been 2 years since exception handling in switch was proposed [0], 3 years since null-restricted types were proposed [1], 4 years since string templates [2], 8 years since concise method bodies [3], and 11 years for JSON parsing [4]. [0] https://inside.java/2023/12/15/switch-case-effect/ https://inside.java/2023/12/15/switch-case-effect/ [1] https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099 [2] https://openjdk.org/jeps/430 https://openjdk.org/jeps/430 [3] https://openjdk.org/jeps/8209434 https://openjdk.org/jeps/8209434 [4] https://openjdk.org/jeps/198 https://openjdk.org/jeps/198
  - MBCook 10mo ago
    Why did Kotlin prevent those features?
    - vips7L 10mo ago
      It didn't. They're examples of features that have driven Kotlin's growth. Thing's Java developers have been begging for. I'm using them as examples of why Java developers are starting to choose Kotlin. I'm a pretty die hard Java fan, I've built my career on it, and know way too much about the ecosystem. But, I've been writing F#, C#, Kotlin, and some other languages in my free time to see where I want to move to. I’m pretty sure C# is what I’ll settle on.
      - MBCook 10mo ago
jeremyjh 10mo ago
In retrospect - from an outside point of view - it seems they should have just declined to support Kotlin. There are other options for Kotlin, and it sounds like it makes sense for it to have something developed for that from the beginning. But probably they had no idea what they were getting into when it was first proposed.

emodendroket 10mo ago

At the end of the day I think there's nothing wrong with the tool itself. The problem is that mocking and spies make it easy to not bother properly isolating the effects of a function for testing and then you end up having a test where 95% of it is setting up an elaborate array of mocks to create the condition you wish to test, which are completely incomprehensible to the next person trying to read it.

lisbbb 10mo ago
I used it mainly because the code I inherited was untestable as written. I made it testable via those methods. Then it got refactored.
- emodendroket 10mo ago
  Well sure you sometimes haven’t got much choice. But I’m talking about people write new code this way

gerdesj 10mo ago

"Wow, there's a lot of anger in some of these posts." If I was OP I'd retire happy knowing that a very thankless job is well done! Given what it does: the more outrage the better. Projects like Mockito call out the lazy and indolent for whom they are and the hissing and spitting in return can simply be laughed at. 10 years this bloke has given his time and effort to help people. He states: nearly a third of his life. I'll raise a glass and say "was hale" or perhaps wassail as an Englander might.

WD-42 10mo ago

Is it anger? The agent thing maybe. The other two points seem to boil down to: 1. Kotlin is a hack and 2. Rust is more fun. Pretty understandable why one would simply want to move on to greener pastures.

vips7L 10mo ago
I'm not sure Kotlin is a hack, but it's growth is directly related to Java not being able to deliver on simple features that would help the day to day lives of developers. So I also can't blame anyone for moving on from the language. I get frustrated with it all the time, especially when Kotlin shows that some feature could work perfectly fine. Here are some examples that have hit the graveyard: It's been 2 years since exception handling in switch was proposed [0], 3 years since null-restricted types were proposed [1], 4 years since string templates [2], 8 years since concise method bodies [3], and 11 years for JSON parsing [4]. [0] https://inside.java/2023/12/15/switch-case-effect/ https://inside.java/2023/12/15/switch-case-effect/ [1] https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099 [2] https://openjdk.org/jeps/430 https://openjdk.org/jeps/430 [3] https://openjdk.org/jeps/8209434 https://openjdk.org/jeps/8209434 [4] https://openjdk.org/jeps/198 https://openjdk.org/jeps/198
- MBCook 10mo ago
  Why did Kotlin prevent those features?
  - vips7L 10mo ago
    It didn't. They're examples of features that have driven Kotlin's growth. Thing's Java developers have been begging for. I'm using them as examples of why Java developers are starting to choose Kotlin. I'm a pretty die hard Java fan, I've built my career on it, and know way too much about the ecosystem. But, I've been writing F#, C#, Kotlin, and some other languages in my free time to see where I want to move to. I’m pretty sure C# is what I’ll settle on.
    - MBCook 10mo ago

jeremyjh 10mo ago

In retrospect - from an outside point of view - it seems they should have just declined to support Kotlin. There are other options for Kotlin, and it sounds like it makes sense for it to have something developed for that from the beginning. But probably they had no idea what they were getting into when it was first proposed.