PluginandPlay_DevoxxBE.pptx

Editor's Notes

• #2: Hello everybody, welcome to my talk Plugin and Play! I am so happy that you choose to come see my talk eventhough it’s the end of the day. Can I see some hands on who has been here since yesterday? And from those people can I see some hands who will stay here until Friday? Wauw, that’s diehard, really cool. Let’s give those people a round of applaus shall we?! Allright, without further adue let’s get started because we only got like 30 minutes.
• #3: I am Simone de Gijt and my buddy Kotlin and I started working in IT from 2016 on. In 2019 he got a big promotion, when Google announced that Kotlin was the preferred language of Android app developers. But it was only until I started working for OpenValue as a Java developer that I really got to play around with him.
• #4: Now in todays talk we will go over 2 plugins, which both will increase the quality of your code base. The first being Kover and the second Detekt. As you can see the structure is quite equal and at the end of each introduction I will give a short demo on how you can configure the plugin for yourself.
• #5: The first plugin we’re going to talk about is Kover. Now you might wonder what Kover is.. Or rather who he is… László Kövér is a Hungarian politician, which is obvious by his moustache. And a little fun fact.. If you would go to a Dutch or Belgium store and ask for a “kover” you would get.. This. You write it a little different though, with double f. But hey, who cares. Okay but all jokes aside: Kover is a gradle plugin for Kotlin code coverage agents: IntelliJ and Jacoco. https://github.com/Kotlin/kotlinx-kover
• #6: Now most of you will probably know what code coverage is, and if not: I would highly recommend you to go to one of the “testing” talks which will probably come up in the next couple of days. But to sum it up: Code coverage is a way by which you can calculate how much of your code has been reached by tests. And calculation, often is visualized like the class file over here. Where green means it has been reached by the tests, red it hasn’t been reached by tests and yellow it only partly has been reached by tests. Now you might already know some code coverage agents that provide this insight for you
• #7: One of them being the code coverage agent provided by IntelliJ IDEA. And if I am honest. This code coverage agent deals very well with Kotlin. Makes sense right, because they are both developed by JetBrains. However, IntelliJ doesn’t provide you a report and therefore the result of the code coverage cannot be exported out of IntelliJ. Making it impossible for you to integrate into your CICD pipeline for example. Oh and.. If you are a Eclipse user, yeah.. Then this is most definitely not an available option for you. The second option you might very well know as it’s quite commonly used. Jacoco. Jacoco stands for Java code coverage and that is precisely what it does. It checks Java code for coverage but unfortunately we are writing in Kotlin. Leading to some issues when we would use it on our code base. Let’s take an example: Source: Kover – The Code Coverage Plugin https://www.youtube.com/watch?v=jNu5LY9HIbw
• #8: I have here a class consisting of 3 methods. The first being an inline function, the second being a method without an input parameter and the last a method with nullable input parameter. Now if I would execute a test that would call upon the greet method with a null as input. How many methods do you think would be hit? The correct answer is three. It first goes into the last method because we enter an input parameter which is null, than that method calls upon the second method and the second method calls upon the inline function. Now if we would have run our Jacoco coverage tool on this code we would get this report:
• #9: Weirdly enough, the inline function has a coverage of 0%. This is because Java doesn’t know about inline functions and therefore it doesn’t register it. Now you might also notice that the nice visualization of a few slides before is gone.. This is because Jacoco doesn’t know about the Kotlin directory structure and therefore can’t find the original class file. But fortunately we have a solution..
• #10: Kover. Kover is a plugin provided by Jetbrains, integrates fully with the gradle toolchain and multiplatform projects. It has some kotlin android support, filters for instrumented classes, exportable reports that you can use in your CICD pipeline and most importantly handles Kotlin features pretty well. Now I could leave it at that, but I feel that I also should give you some of the disadvantages. Sources: Kover – The Code Coverage Plugin https://www.youtube.com/watch?v=jNu5LY9HIbw https://github.com/Kotlin/kotlinx-kover https://kotlinlang.org/docs/multiplatform.html
• #11: First being that Kover came only out in december last year with the mentioning that it is still in an experimental state. Meaning that there can be some bugs, but my experience so far is that Jetbrains is very involved in this project and dedicates time on fixing the bugs pretty quick. Now second disadvantages is that it’s currently only available for Gradle. There is currently an open issue for that, so you can definitely go to the project and give that issue a like. But for now, you need to sit and wait this one out. Or switch to gradle ;)
• #12: Demo: Start with showing that Jacoco is greyed out Show config of detekt Run, show report: inline function + test folders Add excludes: show report Add verify: show build Questions if time
• #13: For our second plugin, we are going to take a look at Detekt. Detekt is a static code analysis tool for kotlin. Now that sounds cool, but what does it analyse?
• #14: It detects code smells. Now code smells can be considered as bad practises. In most cases your code will still work, but the quality.. Meehh not so high. In general code with a lot of code smells is considered hard to read, hard to maintain, hard to understand. Now a small example of a code smell, considered by Detekt would be this if statement with four conditions. Detekt states that this is a “ComplexCondition” and should be reduced to maximum of 3. Now just as with Kover we also have a few options to detect those code smells
• #15: One of them being Sonarqube. Most of you will have heard of it. It is a widely known tool, which generates nice reports. It has both a community as a paid version. So this can also be a nice option. However, because sonarqube is a very extensive tool, I feel it is less plugin-and-play as Detekt is. Second we have megalinter but this is unfortunately not kotlin specific.
• #16: Now some advantages of Detekt are that it has a very configurable rule set and eventough I don’t like to admit it. Code smells are often subjected to personal taste. Now I could spent another talk on how this mindset iss not benefitial for anyone in the long run, but for now let’s skip that and let’s leave it as a positive note that you can change rule sets to make them fit to your liking. Now you also configure quality gates within your build or within your CICD pipeline It has a bunch of integrations. And last but not least there is a possibility to add Ktlint. Now what is Ktlint you might wonder..
• #17: Ktlint is a linter to wipe a kitty clean with
• #18: However, it is also a linter and formatter for Kotlin code, coming from the Pinterest project. In short ktlint detects the code that is not complying to the kotlin code style. So for example; a wrong alfabetical order of imports, wrong indentation or spaces.
• #19: First show detekt plugin and ktlint dependency Show how build fails on both test and main code Show service class -> show plugin (enable ktlint) Change settings Show reports