Testing

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 Some time ago, I’ve written an article about Test coverage report for Android application. It got some interest (many comments below article and many visits according to Google Analytics), so I decided to refresh this topic. Previously, I’ve written instrumentation unit tests, which needed to be executed on a real device or an emulator. It’s a good approach when you want to test functionalities strongly connected with the device. E.g. when you want to test operations on a real SQLite database or something like that. Nevertheless, this approach has huge disadvantages. It’s hard to run tests on the Continous Integration server because we need to have the emulator or device up & connected all the time and also tests need to interact properly with the device to get passed what is not so easy. In most cases, mocking part of the application’s behavior is enough. In that case, we can easily run tests on a CI server and have deterministic test results. In order to do that, we can use Robolectric. ...

Introduction In release cycle of our team at work, we need to perform so-called system tests. In order to do that, we need to log into Artifactory, search for the latest release package, check if it’s up to date, download it, unzip it, install internal configuration recipe, compile, initialize & run it. Not all of that can be easily automated, but I thought that at least searching & downloading phase can be done from the terminal in a semi-automated way. That’s why I created ydownloader shell script. ...