<@U0FLRRSQK> and I having fun trying to migrate away from Spring Boot <https://youtu.be/nSvujHAjV2U...

# feed

[dmcg]

@Dmitry Kandalov and I having fun trying to migrate away from Spring Boot

https://youtu.be/nSvujHAjV2U▾

[Matteo Mirk]

Yes! This is so cool, definitely watching it! We need more content like this K

[Big Chungus]

Title is quite misleading though.

[Dmitry Kandalov]

@Big Chungus what did you expect after reading the title?

[Big Chungus]

Literally migrating java code to kotlin code in spring boot app. End result being same string boot app just rewritten in kotlin.

[Dmitry Kandalov]

Thank you! We didn’t realise it can be interpreted like that. Duncan wrote a book “Java to Kotlin: A Refactoring Guidebook” so I thought replacing “Java” with “Spring” would make sense alluding to Spring being nearly a programming language. This was probably too clever 🤨

[dmcg]

I think the title tells you exactly what we did! It describes the start and end states.

Had we refactored a Spring Boot app from Java to Kotlin, surely the title should have been Refactoring from Spring Boot to Kotlin and Spring Boot?

[Big Chungus]

In your own words:

@Dmitry Kandalov and I having fun trying to migrate away from Spring Boot

Additionally the video ends with spring boot replaced with http4k.

[Big Chungus]

Here's how I'm deciphering it:
Spring boot is a framework
Spring boot historically is written in java language
Kotlin is not a framework
Kotlin is a language, therefore it must relate to java

So "Refactoring from Spring boot to kotlin" probably implies "Refactoring Spring boot java to kotlin" from which I'd expect language level changes within spring boot context

[Big Chungus]

BTW, I'm not trying to pick on anyone here. Just a piece of honest feedback.

[dmcg]

And, honestly, the purpose of the title is to persuade you to watch the video!
Feedback on Reddit shows that other people interpreted the title the same way, so you aren't alone.

[dmcg]

We came to the conclusion (although might not have said it in the video) that Spring Boot is effectively a language on top of Java/Kotlin - classpath scanning and annotations change the way that the source is interpreted. The inital app is therefore a Spring/Kotlin app, with Kotlin just defining the algorithmic bits. The final app is pure Kotlin, using the facilities of the language to define how it is wired in place of Spring Boot.

[dmcg]

If people truly watch the video hoping to see how to refactor from a Java app to a Kotlin one then we may disappoint, although nowhere do we mention Java. There are plenty of tutorials covering that material though. Once you know enough Kotlin to do the translation I think the video gives some helpful tips on using Spring with Kotlin - prefer lateinit to nullable, and ctor injection to both, lazy properties may dig you out of a hole…

[kqr]

I too find it kind of misleading, but nice from content perspective. anyway I guess almost all refactorings could be made in java too, so it was more like removing spring magic

[Jacob]

Hmm... I think I'll go refactor my mug to coffee now

[dmcg]

That's the way - fewer containers FTW!

[Dmitry Kandalov]

Here is another (shorter and better ✨) version of the pairing session in which @dmcg and I refactor dependency injection from Spring to pure Kotlin

https://www.youtube.com/watch?v=Y6xBVQI9gSc▾

[박재현 (박재현)]

hi, @Dmitry Kandalov @dmcg

I found something interesting about writing a test class in the video.

These days, I don’t feel the need for an @SpringBootTest annotation when I write a unit test. (Same as you)

However, most Spring users use the @SpringBootTest annotation for unit testing. (It doesn’t seem welcome, especially for a follower of classical test styles. 🤣 )

I think there are two advantages of a unit test that is written in this way (not using @SpringBootTest).

1. test code is not dependent on the spring.
2. Light and fast
However, sometimes unit tests using Spring require @SpringBootTest (for example, when write a unit test for SUT using JPA)

I am confused by these two conflicting case.
and my definition of unit test writing is fading.

I really want to know the specific reason why you don’t use “@SpringBootTest” for the unit test.

[Jacob]

Dependency injection should make your code less dependent on the container than it would be with traditional J2EE / Java EE development. The POJOs that make up your application should be testable in JUnit or TestNG tests, with objects instantiated by using the new operator, without Spring or any other container. You can use mock objects (in conjunction with other valuable testing techniques) to test your code in isolation. If you follow the architecture recommendations for Spring, the resulting clean layering and componentization of your codebase facilitate easier unit testing. For example, you can test service layer objects by stubbing or mocking DAO or repository interfaces, without needing to access persistent data while running unit tests.

True unit tests typically run extremely quickly, as there is no runtime infrastructure to set up. Emphasizing true unit tests as part of your development methodology can boost your productivity. You may not need this section of the testing chapter to help you write effective unit tests for your IoC-based applications. For certain unit testing scenarios, however, the Spring Framework provides mock objects and testing support classes, which are described in this chapter.

^From springs own docs https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#unit-testing

If most developers use @SpringBootTest for all unit tests then they're doing it wrong

[Craig]

I haven't watched the full video yet but I can relate to your questions on testing. IMO writing maintainable useful tests can be difficult and 5 different developers may tell you 5 different patterns. People even argue over the terminology of tests. I would argue if you are pulling in the spring runtime for your tests (either @Spring*Test annotations or manually building the app context) then they are not "unit tests" but a form of "integration tests", and there should be a difference in your application for them. I'm a fan of "narrow integration tests" as defined here which limits the need to wire spring in for only the edges of your app - and using test containers for those external resources.

[박재현 (박재현)]

@Craig good, of the same mind

[박재현 (박재현)]

@Jacob good reference. thank you