Testing Coroutines — Update 1.6.0
About one year ago I wrote some articles describing the Kotlin Coroutines Testing module. With the recent 1.6.0 release things changed significantly, so it’s time for an update. Read the article on medium...
Posts
Testing Coroutines — Dispatchers
In part one and two of this series we saw how to make use of the time control features of the kotlinx-coroutines-test module. In this part you will see how to test code that utilizes a dedicated dispatcher. Read the article on medium...
Testing Coroutines — Timeout
The first part of this series provided you an introduction to the building blocks of the kotlinx-coroutines-test module, and gave you some examples on eager execution and virtual time. In this second part we will have a look at testing timeouts. Read the article on medium .
Testing Coroutines — Introduction
This is the first part of my little series on testing coroutines, where we will explore the capabilities of the kotlinx-coroutines-test module. All examples (and some utility functions) are provided in a Git repository, so give it a try. This first part will introduce the building blocks of the module, and give some examples on eager execution and virtual time. Read the article on medium .
JUnit 5 - Part II
In the first part , I gave you a brief introduction to the basic functionality of the new JUnit 5 framework: new asserts, testing exceptions and timing, parameterizing and structuring tests. In this part I will explain the extension mechanism, which serves as a replacement for the runners and rules. The New Extension Model JUnit 4 introduced the concept of runners, which allowed you to implement a strategy on how to run a test. You could specify the runner to use by attaching the @RunWith annotation to the test class, where the value of the annotation specified the runner class to use. You could do quite a lot of stuff with runners, but they had one central drawback: you could specify only one runner on a test :-| Since this was not flexible enough for most people, they invented the concept of rules. Rules allows you to intercept the test execution, so you can do all kind of stuff here like test preparation and cleanup, but also conditionally executing a test. Additionally y...
JUnit 5 - Part I
More than a decade ago I wrote an introduction to JUnit 4 , which was – to be quite honest – just a catch-up with the more advanced TestNG. Now JUnit 5 is in the door and it is a complete rewrite, so it’s worth having a fresh look on it. In the first installment of this two part article I will describe what’s new in the basic usage: new asserts, testing exceptions and timing, parameterizing and structuring tests. JUnit 5 comes with a comprehensive user guide , most examples shown in this part are taken from there. So if you already read that, you may skip this and continue directly with the second part, which describes the new extension API that replaces the old runner and rules mechanisms. One Jar fits all? Prior to JUnit 5 all parts of the JUnit framework has been packed into one jar: the API to write tests - e.g. assertions - and the API and implementation to actually run tests; for some time, even hamcrest was baked into it. This was a problem ...
Give me a ping Vasily, Part I
Writing integration tests is not an easy task. Besides the business complexity, it is also often not easy to set up a suitable test scenario. This article will show an easy way to write integration tests for common problems in Eclipse based client-server projects. It started in a meeting with project management. The leader of a large-scale SmartClient project asked: "How come we have so many unit tests, but only a few integration tests?". I guess the main problem was that the application was based on large, interweaved (host) database tables, and we were not allowed to alter any data...even in the test environment. So in fact, we could not set up any test data, we were forced to set up our test cases on the existing data. But it was living data, and so it was subject to change. Means: even if you had set up a test based on that data, it was very expensive to maintain. The project leader claimed: "We need a kind of integration test that is easy to write, needs no maintena...
Give me a ping Vasily, Part II
This is the second part of a two-part article on Ping. The first part gave you an instroduction to the Riena Ping API. This second part will show you the usage of the Sonar UI to run ping tests. The first intention was to use ping for automated, JUnit -driven, integration tests. But that did not work out for two reasons: The build server supposed to run the tests was a unix system, but the client was targeted for windows. The build server was located in the intranet and was not allowed to connect to the application server. During discussion of these problems, one of the infrastructure guys said: "Wouldn't it be cool, if we could use those ping tests as part of our daily system check?" Bingo! That's the idea. Instead of preparing a client-like test setup, just integrate the tests into the client. And that's what Sonar is all about: A UI dedicated for running ping tests, that could be easily integrated into any ( Riena -based) client product: No need to say that it...