Java

During development process, we often write unit and integration tests. While unit tests verify corectness of the small pieces of code, integration tests verify software as a whole project and sometimes can treat it as a black box where concrete results are expected. During development of the REST API, we can write integration tests for such API with REST Assured. Integration tests are usually slower, because they need to start the server and sometimes do other stuff. That’s why it’s good to separate their execution from regular unit tests. On the CI server we can even have separate job for them. ...

I recently wrote a simple java app with Dagger 2 as a DI container and Gradle as a build system. I wanted to generate unit test coverage report for this app, so I used Jacoco. In my build.gradle file I configured JaCoCo as follows: plugins { id 'jacoco' } jacocoTestReport { reports { xml.enabled = true html.enabled = true } } Now, I could type: ./gradlew test jacocoTestReport Report was generated in build/reports/jacoco/ directory. I noticed that report includes Java code generated by Dagger during the compilation. I didn’t want to include it in the report because it doesn’t really make any sense to write unit tests for generated code. ...

In Java, we can test exceptions via unit tests in a few different ways. In this article, I’ll present common methods of doing that. Nevertheless, I suppose we there are different methods as well. First method is basically wrapping a method call with try-catch block, assigning an exception to a variable and performing appropriate assertion. In these examples, I’m using JUnit for unit tests and Truth for assertions. @Test public void shouldTestExceptionWithTryCatch() { Exception caughtException = null; try { throw new RuntimeExcetpion("message"); } catch (final Exception e) { caughtException = e; } assertThat(caughtException).hasMessageThat().isEqualTo("message"); } In the second method, we can define a type of the thrown exception within the @Test annotation. It’s useful approach when we don’t want to test exception details like message and we care only about the type. ...

Introduction Recently, I decided to create a tiny Android library called RxBattery, which is monitoring battery state of the device with RxJava and RxKotlin. I created a few Java and Android libraries already and this time I decided to use Kotlin programming language instead of Java to learn something new and write something more complicated than “Hello World” app. Here are my observations. Build System I used Gradle to build the project. It’s popular for JVM and Android apps nowadays and works fine with Kotlin. I just needed to add Kotlin Gradle Plugin and Kotlin STD Lib to the /library/build.gradle file to the classpath dependencies in buildscript section. I also needed to define sourceSets to allow IntelliJ and Android Studio recognize directories with sources. ...

Today, I’ve released next version of my most popular open-source project - ReactiveNetwork. I’ve released version 0.12.4 for RxJava1.x and version 1.0.0 for RxJava2.x. Please note, RxJava1.x is no longer officially supported and I’m going to follow the same approach in my RxJava-based projects. It’s not the first release of this project, but I’m breaking the API and removing existing methods, so I decided to stick to proper versioning standard. I didn’t always do it properly in the past, but it’s never too late. ...