DEV Community: Victor Gallet

Why you should stop doing code reviews!

Victor Gallet — Wed, 03 Jan 2024 13:32:00 +0000

I would like to thank Baptiste Barbieri, Antoine Guy, Maxence Zajdlic and Rafael S. Ward for their time <3.

Code review is one of the most used methods in software development. We all know what are the benefits of doing code review.

To sum up, doing code review enables verification of new code quality by identifying future bugs, ensuring tested code, and ensuring readable code.

Moreover, by reading code written by others, developers can learn from others. A junior developer can learn by reading the code of a more experienced one. They can ask questions using comments.
Vice versa a senior developer can check the code of a junior developer and provide constructive feedback.

I won’t go deeper into code review benefits in this article. For more information, you can read the amazing work done by Trisha Gee. For instance this blog post.

However, is code review really worth doing? What are the drawbacks we faced doing code review? I tried to list all code review antipatterns I faced and I’m sure you faced some of them. Several times.

Code review pitfalls

The “ping pong” review

Some comments are added, you take them into account, some new comments are added, you take them into account, new comments are added…and so on. It’s really frustrating for the merge request author, even more when it happens with several reviewers.

The “re-design” review

Once the merge request opens, you receive comments indicating a large design issue. It’s not a simple correction, but the whole implementation must be redone. This is a demoralizing situation for the author and the reviewers and a waste of time.

The “ghosting” review

Comments are added, taken into account and then you wait for the approval. The reviewer has disappeared and you have to wait before merging. Even if other reviewers have approved the merge request, you have to wait for the ghost reviewer.

The “waiting for” review

Your merge request is not the most attractive and you are still awaiting approval.

The “TL;DR” review

Changes are very important but reviewers didn’t read it before approving it because it was too long.

The presentation review

You have done a huge refactoring or the changes you bring are really complex to review and your team is asking you for a presentation or a mob review. Now you have to find a time where everyone is available to do the code review, it’s only the beginning of your merge request journey.

The “convention style” review

Some comments on the merge request are merely about coding style. For instance, there are too many break lines or spaces. Those kinds of reviews could be avoided with a linter.

The “too small” merge request

If one line of code has been modified, you tend to think that it will be approved and merged fast. BUT! Instead, it triggers a lot of discussions. We are typically in a bike-shed effect.

The “keep rebasing” review

Your merge request is waiting for approval, while other merge requests are merged and you have to keep your code up to date and potentially resolve conflicts.

The “inconsistent feedback” review

Sometimes you get a comment and don’t know how to handle it. Most of the time, the review expressed a feeling more than a clear solution. For example “This function seems too complicated for me”.

The “after merged” review

The merge request has been approved and merged. Great! But a new challenger has appeared! This challenger is perhaps knowledgeable about the project or on the technologies used and he wants to make some changes. Most of the time, a new merge request will be opened by this person without sharing it with the first developer.

The “conflict” review

Expressing or receiving feedback can be complicated, people can take it personally and it can lead to some tensions in the team.

The “elderly” merge request

The merge request is open for a long time, it could be a couple of weeks, a month or even a year. The merge request is so old that most of the developers don’t know if it’s still relevant to merge it so the merge request will just sit there.

The “not working” review

The CI pipeline passed, and the merge request has been approved but once merged and deployed... it doesn’t work! Let’s do a full cycle again.

The “Full-time job” review

Code review can be a full-time job! A developer in a team could spend their entire time doing code review. Furthermore, it’s not uncommon to have developers in a team who are spending way more time than others doing code reviews. Not everyone does code review in a balanced way and it can lead to struggles within the team.

The worst thing about all those patterns is that they can be accumulated. You can be in a ping pong review, suddenly land on with a ghost review, keep rebasing and finish by having some tensions in your team.

Stop doing code review?

So what are the solutions to avoid those situations? Most of these problems could be avoided by sharing early. Before what?
For instance, sharing about coding guidelines, architecture, coding practices or design before jumping into the code. All of these methods and practices are living, moving with time and have to be updated during the project lifecycle.

It’s merely an Agile value: having feedback as soon as possible. Feedback coming from code review is too late.

In my experience, code review creates more problems than it solves. Code review is only good when developers work mostly in an asynchronous way and in different time zones. But in most cases, developers are working in the same team, on the same project at the same time and code review is only a way to avoid exchanges with colleagues. Nowadays, code review is a cargo cult.

Most of the time code review should be replaced by pair programming or better still ensemble programming (also known as mob programming).
In that way, you have at least two people working on the same piece of code and you always have:

knowledge sharing, both business and technical knowledge
proof-reading
developing cohesion and team spirit

Doing pair programming, doing synchronous development saves from ghosting, from ping pong comments, “TL;DR” review, “waiting for” review, “convention style” review….and so on. Actually, working together avoids all of the pitfalls of code review.

If you are developing using TDD, pair programming can even be more fun by doing ping pong pair programming.

Lastly, I won’t debate about the simplistic idea that having two developers working together on the same task is more expensive compared to having them working alone. The synchronisation process in all steps is one of the most expensive and code review is one of them.

Originally published at https://vgallet.github.io on December 14, 2023.

Some cool features you may not know about Apache Kafka

Victor Gallet — Fri, 18 Jun 2021 08:10:44 +0000

Apache Kafka is a widely distributed event streaming platform. In this article, I won’t explain Apache Kafka fundamentals like what’s a topic, a partition, an offset nor In-Sync Replicas. You can find a lot of resources to learn how Apache Kafka works and its fundamentals. I will present to you some features you may not have heard about.

Metric Reporters

You may already know that Apache Kafka Clients: Producer and Consumer, can be monitored using JMX metrics. You can browse all the JMX metrics exposed for a Consumer here and for a Producer here.

By default, Apache Kafka Clients exposed the JMX Metrics using the class JmxReporter. This class implements the interface MetricsReporter

public interface MetricsReporter extends Reconfigurable, AutoCloseable {
    void init(List<KafkaMetric> var1);

    void metricChange(KafkaMetric var1);

    void metricRemoval(KafkaMetric var1);

    void close();

    default Set<String> reconfigurableConfigs() {
        return Collections.emptySet();
    }

    default void validateReconfiguration(Map<String, ?> configs) throws ConfigException {
    }

    default void reconfigure(Map<String, ?> configs) {
    }

    @Evolving
    default void contextChange(MetricsContext metricsContext) {
    }
}

And so you can define your own way to expose those Kafka Metrics by implementing this interface and setting the configuration metric.reporters

settings.put(ConsumerConfig.METRIC_REPORTER_CLASSES_CONFIG, List.of(MyMetricReporter.class));

Client Interceptor

Client Interceptor lets you intercept received or produced records and possibly mutate them. For each Apache Kafka Clients: Producer and Consumer, you can define interceptor classes.

For the producer, you have to implement the interface ProducerInterceptor

public interface ProducerInterceptor<K, V> extends Configurable {
    ProducerRecord<K, V> onSend(ProducerRecord<K, V> record);

    void onAcknowledgement(RecordMetadata var1, Exception exception);

    void close();
}

For the consumer, it’s the interface ConsumerInterceptor

public interface ConsumerInterceptor<K, V> extends Configurable, AutoCloseable {
    ConsumerRecords<K, V> onConsume(ConsumerRecords<K, V> records);

    void onCommit(Map<TopicPartition, OffsetAndMetadata> partitions);

    void close();
}

Once you have implemented those interfaces, add your interceptors to the client using the configuration interceptor.classes.

settings.put(ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG,
        List.of(MyConsumerInterceptor.class));

This is particularly useful if you use Apache Kafka in a microservices architecture and you want to add tracing supervision. For example, using OpenTracing you can take a look at opentracing-contrib/java-kafka-client that provides TracingProducerInterceptor and TracingConsumerInterceptor. Those interceptors inject and retrieve span context from record headers.

Partition Assignment & Co-partitioning

Let’s say you have 10 topics, each topic has 1 partition and you create a consumer group with 10 consumer instances. How will the consumers assign each partition? You may suppose that one consumer consumes one partition...In fact, it depends on the strategy used to assign the partitions amongst the consumer instances.

By default, the consumers are configured to use the RangeAssignor. This strategy’s goal is to co-localized the partitions of each subscribed topic to the same consumer. And so, to answer the first question, one consumer will be assigned to all the partitions and the other consumers remaining will be idle.

This strategy used by default is designed to be used with co-partitioning topics. Co-partitioning topics are topics with the same number of partitions and where messages are produced with the same partitioner and the same partitioning key.
However, if your goal is to maximize the number of consumers used in your consumer group, you should change the default assignment strategy using the property partition.assignment.strategy to use the RoundRobinAssignor

Rack Awareness

By specifying the property broker.rack on each broker of the cluster, Apache Kafka will spread replicas of the same partition across all the specified racks. This feature limits the risk of data loss if a rack goes down. A rack can be a cloud provider zone or a data center location.

However, Apache Kafka clients always interact with the partition leader, so it can be a problem if your clients are located in a different zone from the broker leader.

In this diagram, the consumer is located in zone-B, and the partition leader is located in zone-A. It increases the number of cross-zone requests and can increase the billing at some cloud providers.
To avoid this issue, Apache Kafka 2.4 introduces the notion of Follower-Fetching. It means that a consumer can fetch data directly from a follower instead of from the partition leader. To enable this feature, brokers have to set the property broker.rack with the desired location and replica.selector.class with org.apache.kafka.common.replica.RackAwareReplicaSelector. On the other hand, Consumers have to set client.rack to tell in which location they are.

Kafka Lag Exporter

Kafka Lag Exporter is not part of the Apache Kafka project nor the Confluent Platform. It’s an open-source project under Apache-2.0 License to export Consumer Lag with reporters like Prometheus, Graphite, or InfluxDB. Kafka Lag Exporter enables to monitor Consumer Lag but it also allows to estimate the Time Lag. This metric shows how far a Consumer group is behind the last produced record in terms of time. It shows the actual latency of a consumer application. For more information about this estimation, you can read the chapter of the documentation Estimate Consumer Group Time Lag

Cluster Linking

In a Multi Data Center architecture, Cluster Linking is the ability to create a link between two distincts Apache Kafka clusters. Once the link is established, you are able to mirror topics.
Mirroring a topic means that all the data from a topic and its configuration in the source cluster is replicated to a topic with the same name in the destination cluster.

Unlike, Replicator and MirrorMaker2, Cluster Linking does not require running Connect to move messages from one cluster to another, ensuring that the offsets are preserved from one cluster to another. We call this “byte-for-byte” replication. Whatever is on the source, will be mirrored precisely on the destination cluster.
https://docs.confluent.io/platform/current/multi-dc-deployments/cluster-linking/index.html

The destination topic does a “byte-for-byte” replication, it preserves the offsets from one cluster to another and it also replicates source topic configuration like retention, number of partitions from the source topic.

Cluster Linking is a really promising feature but it’s currently a preview feature.

A preview feature is a component of the Confluent Platform that is being introduced to gain early feedback from developers. This feature can be used for evaluation and non-production testing purposes or to provide feedback to Confluent.

Confluent provides a demonstration project to play with this feature.

Tiered Storage

Tiered Storage is the ability to store the data into external storage instead of the local disk of your brokers. The idea is to separate the concerns of data storage from the concerns of data processing. It allows you to retain your data for months, years, or indefinitely.

You can configure your Apache Kafka cluster with one of the three supported tiered storage: AWS S3, GCP GCS, and Pure Storage FlashBlade.

For example with Amazon S3:

confluent.tier.feature=true
confluent.tier.enable=true
confluent.tier.backend=S3
confluent.tier.s3.bucket=<BUCKET_NAME>
confluent.tier.s3.region=<REGION>

And then you can create a topic with tiered storage

kafka-topics --bootstrap-server localhost:9092   \
  --create --topic tiered-storage-topic \
  --partitions 6 \
  --replication-factor 3 \
  --config confluent.tier.enable=true \
  --config confluent.tier.local.hotset.ms=3600000 \
  --config retention.ms=604800000

retention.ms works the same as a normal topic. It defines the time you want to keep your data in the local storage or in the tiered storage.

confluent.tier.local.hotset.ms defines the time in milliseconds a non-active segment is retained on the local storage. Once it’s expired, the segment is deleted from the local storage and saved to the tiered storage.

References

The day I erased all the customer data

Victor Gallet — Sat, 23 May 2020 15:37:25 +0000

Photo by Sarah Kilian on Unsplash

This story takes place in a company where I previously worked. Back then, I was a young developer and I was tasked with the deletion of former customer’s data.

I checked the database and identified all the tables that would be impacted. Then, I wrote a SQL script to delete all the rows concerning this particular customer.
This script was not directly executed in the production environment. Instead, all changes are included in a version control system tool equivalent to Liquibase or Flyway.

A few days later, our support team received a phone call from a customer who could no longer find his data on the application. After performing an investigation, we came to the realization that all customer data were deleted from the database. The main culprit was none other than my SQL script. Indeed, some DELETE SQL statements were missing the WHERE clause. In the meantime, the ops team tried to restore the production database with the most recent backup.

At that time, I was petrified and I dreaded what my boss could say to me.

To my surprise, he did not single me out but blamed all the team and particularly our quality checks. In fact, he simply wanted to answer this question: How could this blunder have made its way to the production environment?

First of all, the SQL script was merged on the master branch, with at least 2 approbators on my pull request. So, it means that our code review was not thorough enough.
Secondly, this script passed all our End to End tests and manual testing.
Finally, we discovered that the database backup system was not working properly and the last available backup was at least 2 months old. Luckily, it had a fairly limited impact on our business, since it happened during summertime.

In my opinion, we can learn two things about this little story. In the first place, a good team and a good manager will not put the blame on you if you have done a mistake. Everyone makes mistakes and it’s a good way to question some of the practices.
In the second place, it is important for a team to insure itself against the risk of fault, error or minor oversight. Despite quality processes, it’s important to test and prove those processes.

Thanks to Marc Barret for his time and his review

Workshop Azure Pipelines

Victor Gallet — Fri, 24 Apr 2020 09:34:19 +0000

I have been working with Azure Pipelines for some time and I would like to introduce it to you. Instead of describing it into a blog post, I made an online workshop to manipulate it.

During this workshop, you will learn how to set up a CI pipeline to build a Maven / Java application and a NodeJs application. You will also discover Azure Pipelines features, such as pipeline caching, variables, parameters, and templating.
If you would like to take this workshop, all you need is a Github account.

Please feel free to send me feedback here on the comment section or by creating a Github issue to the project.

Here's the link https://workshop-azure-pipelines.netlify.app/

Add chaos in your network!

Victor Gallet — Wed, 11 Dec 2019 19:34:13 +0000

An important rule in production is to never trust your network! There will always be problems and Netflix has clearly understood this statement by creating Chaos Monkey in 2011.
In this article, we will focus on chaos in the network. For example to assert that:

an application is resilient to network latency
a website still offers a comfortable experience despite a limited bandwidth
a distributed system cannot go into split-brain.

tc is a Linux command to manage network traffic. For example:

tc qdisc add dev eth0 root netem delay 200ms

This command add 200 milliseconds latency on the network of eth0 interface. Let’s dissect it.

As quoted from linux man page, qdisc is

short for 'queueing discipline' and it is elementary to understanding traffic control.
Whenever the kernel needs to send a packet to an interface, it is enqueued to the qdisc configured for that interface.
Immediately afterwards, the kernel tries to get as many packets as possible from the qdisc, for giving them to the network adaptor driver.

add is to add a new rule.

dev eth0 means the rule is applied to the device, the network interface eth0.

root is the class attached to the network packet. In this case, the rule is applied to all packets.

netem means Network Emulator. It’s the tool to add a behaviour.

delay 200ms is the rule to apply. Here it’s a 200 milliseconds latency.

Once the rule is applied, we can list all the rules applied to eth0.

tc qdisc show dev eth0

And to delete it

tc qdisc del dev eth0 root

In the first example, the latency impacts the whole network, including a ssh connection. In order to not impact all the network but only a port, an IP or a range of IP, it’s possible to use the class concept of qdisc.
By default, a qdisc is divided into 3 bands: 0, 1 et 2. This command helps to see these bands:

tc qdisc ls

qdisc noqueue 0: dev lo root refcnt 2 
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

On my computer, eth0 has 3 bands with a priority map of 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1.
The band used is determined by network packet TOS. TOS stands for Type Of Service. This is simply four bits indicating the type of priority.

Binary Decimal  Meaning
-----------------------------------------
1000   8         Minimize delay (md)
0100   4         Maximize throughput (mt)
0010   2         Maximize reliability (mr)
0001   1         Minimize monetary cost (mmc)
0000   0         Normal Service

Here’s the table used to determine the band. There is more explanation of how it works directly on the man page.

First of all, a rule is added to change the priority map. All the traffic will go to the first band.

tc qdisc add dev eth0 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Next, this rule defines the behaviour added but only on the third band. Here it’s a delay of 1000 milliseconds.

tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 1000ms

Finally, a filter is applied to redirect all the traffic matching a destination IP to the third band. To ensure it works correctly, a simple ping to that IP does the trick.

tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst <mon ip> flowid 1:2

64 bytes from <server> (<mon ip>): icmp_seq=143 ttl=62 time=1000 ms
64 bytes from <server> (<mon ip>): icmp_seq=144 ttl=62 time=1000 ms
64 bytes from <server> (<mon ip>): icmp_seq=145 ttl=62 time=1000 ms
64 bytes from <server> (<mon ip>): icmp_seq=146 ttl=62 time=1000 ms
64 bytes from <server> (<mon ip>): icmp_seq=147 ttl=62 time=1001 ms

The rule is correctly applied. Here it’s using a filter on an IP but it works with a subnet mask and/or a port. For example:

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst <mon IP> match ip dport <mon port> 0xffff flowid 1:2

Other options

Here some other possibilities.

netem delay 100ms 10ms

this rule adds 100 milliseconds of delay plus or less 10 milliseconds in an uniform disribution.

netem loss 10%

10% of packets are loss.

netem duplicate 50%

50% of packets are duplicated

netem corrupt 5%

5% of packets are corrupt.

Limit bandwidth

Finally, the tool Token Bucket Filter (TBF) enables to limit the outgoing bandwidth.

tbf rate 20kbit buffer 1600 limit 3000

The outgoing bandwidth is limited to 20 kilobits.

A big thanks to Marc Barret for his time and proofreading.

Photo by American Public Power Association on Unsplash

PostgreSQL Replication

Victor Gallet — Tue, 10 Dec 2019 20:09:16 +0000

There are plenty of tutorials available online, which give step-by-step instructions to manage the replication of PostgreSQL clusters with Repmgr. Once the setup is complete, what is important to look for? How does your client handle failover? How to deal with a failed or unreachable standby node? How to reintegrate a failed or unreachable standby node? How do you monitor your cluster?

Client Failover

When your primary node goes down and a standby is promoted. How do you let your clients handle this change?

Official driver

A simple solution is to use official driver capabilities. As mentioned in the documentation, you can list all nodes in your cluster and the connection will be established only on the primary node.

jdbc:postgresql://primary,standby1,standby2/database?targetServerType=master

In this situation, the primary node will handle all the read and write queries. However, it’s possible to create a second connection dedicated to read queries on standby nodes.

jdbc:postgresql://primary,standby1,standby2/database?targetServerType=preferSlave

Handmade solution

It’s possible to create your own solution to enable connection failover. For example in this article, a shell script is used to check PostgreSQL status and HAProxy is used to perform failover.

Repmgrd

Repmgrd is the Repmgr daemon. It monitors the PostgreSQL cluster and performs necessary actions based on the state of the cluster. It performs automatic failover in the case that the primary node goes down by promoting the most eligible standby as the new primary.

Repmgrd is a critical process that should be running at all times. The failover mechanism would not be able to kick in if it were to stop working.
Therefore, it is highly recommended to enable “auto restart” by overriding the provided daemon’s configuration file with systemd.

.include /lib/systemd/system/repmgr.service
[Service]
Restart=always
RestartSec=10
StartLimitInterval=60
StartLimitBurst=3

With this configuration, the daemon will be restarted in case of failure after a timeout of 10 seconds. It will try 3 times during an interval of 60 seconds. In any case, if Repmgr daemon is going down, it means there is a problem with the service or on the server and simply restarting the service may not fix the issue.

Promotion

Promoting a new primary is one of the most important actions during a failover situation. Repmgr knows when by doing reconnect attempts. Depending on the quality of your network, you may need to avoid promotion caused by network latency by modifying reconect_attempts and reconnect_interval

# Number of attempts which will be made to reconnect to an unreachable primary (or other upstream node)
reconnect_attempts=6                                                          

# Interval between attempts to reconnect to an unreachable primary (or other upstream node)
reconnect_interval=10

With this configuration, a total of 6 attempts will be made with 10 seconds between attempts before promoting a new primary using promote_command.

As you can see from the documentation, promote_command in Repmgr configuration is used in a failover situation to promote a new primary. Example:

promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'

In fact, in the case of a failover situation, something wrong is happening so it may be a good action to perform a backup in addition to promotion. For example, this command will perform a backup using pgbackrest.

promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file && sleep 120 && pgbackrest --stanza=my_stanza --type=full backup'

Monitoring

PostgreSQL Replication statistics are available on current primary. An overall vision can be seen on primary node by executing:

select * from pg_stat_replication;

pg_stat_replication contains statistics about each WAL sender process connected to a standby process.

-[ RECORD 1 ]----+----------------------------------------------
pid              | 11881
usesysid         | 16388
usename          | repmgr
application_name | <application_name>
client_addr      | <ip>
client_hostname  | 
client_port      | 58212
backend_start    | 2019-11-12 16:52:04.51763+01
backend_xmin     | 
state            | streaming
sent_lsn         | 138/6C000000
write_lsn        | 138/6C000000
flush_lsn        | 138/6C000000
replay_lsn       | 138/6C000000
write_lag        | 
flush_lag        | 00:00:00.29105
replay_lag       | 
sync_priority    | 0
sync_state       | async
-[ RECORD 2 ]----+----------------------------------------------
pid              | 11879
usesysid         | 16388
usename          | repmgr
application_name | <application_name>
client_addr      | <ip>
client_hostname  | 
client_port      | 35170
backend_start    | 2019-11-12 16:52:03.053909+01
backend_xmin     | 
state            | streaming
sent_lsn         | 138/6C000000
write_lsn        | 138/6C000000
flush_lsn        | 138/6C000000
replay_lsn       | 138/6C000000
write_lag        | 
flush_lag        | 00:00:00.268068
replay_lag       | 
sync_priority    | 0
sync_state       | async
-[ RECORD 3 ]----+----------------------------------------------
pid              | 5201
usesysid         | 16388
usename          | repmgr
application_name | <application_name>
client_addr      | <ip>
client_hostname  | 
client_port      | 52130
backend_start    | 2019-11-08 16:22:01.688119+01
backend_xmin     | 
state            | streaming
sent_lsn         | 138/6C000000
write_lsn        | 138/6C000000
flush_lsn        | 138/6C000000
replay_lsn       | 138/6C000000
write_lag        | 
flush_lag        | 00:00:00.23605
replay_lag       | 
sync_priority    | 0
sync_state       | async

First of all, sync_state column indicates what type of replication used. In this example, the value async only shows that is an asynchronous replication and it’s definitely not a problem as I have seen explained in some articles. When you setup a replication cluster, you had to choose between asynchronous and synchronous replication.

In postgresql.conf file, it’s possible to specify a list of standby servers to support synchronous replication with synchronous_standby_names. It means that transactions will commit only after standby synchronous servers confirm receipt of the data.

What is important to look is state column. Value streaming indicates the WAL sender is streaming changes to its connected standby server. Then, an important health indicator is the amount of WAL records generated the primary node, but not yet applied by standby server: streaming lag.

sent_lsn shows the last WAL sent on WAL sender connection. LSN stands for Log Sequence Number and it’s a position in the Write-Ahead Log stream. Thus, an important gap between current WAL and sent_lsn may indicate that primary server is under heavy load. We can get current WAL by using pg_current_wal_lsn function and pg_wal_lsn_diff to compute the difference.

select (pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn)) as primary_streaming_lag FROM pg_stat_replication;

The result is in bytes.

The view pg_stat_replication provides also the last WAL position written, flushed and replayed on standby database. This way, we can have the standby total streaming lag by executing this query for each standby node :

select (pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn)) as standby_streaming_lag FROM pg_stat_replication;

select application_name,
pg_current_wal_lsn() as current_WAL_lsn,
sent_lsn as last_sent_WAL,
replay_lsn last_replay_WAL,
(pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn))::int / 1024 as primary_streaming_lag,
(pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn))::int / 1024 as standby_streaming_lag
FROM pg_stat_replication;

Let’s check this query by adding some network latency

tc qdisc add dev eth0 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 1000ms
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst <ip mask> flowid 1:2

This command adds a delay of 1 second for nodes that match a specific IP range.

select application_name,
pg_current_wal_lsn() as current_WAL_lsn,
sent_lsn as last_sent_WAL,
replay_lsn last_replay_WAL,
(pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn))::int / 1024 as primary_streaming_lag,
(pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn))::int / 1024 as standby_streaming_lag
FROM pg_stat_replication;

-[ RECORD 1 ]---------+----------------------------------------------
application_name      | <application_name>
current_wal_lsn       | 138/7D054AF8
last_sent_wal         | 138/7D054AF8
last_replay_wal       | 138/7D054AF8
primary_streaming_lag | 0
standby_streaming_lag | 0
-[ RECORD 2 ]---------+----------------------------------------------
application_name      | <application_name>
current_wal_lsn       | 138/7D054AF8
last_sent_wal         | 138/7D054AF8
last_replay_wal       | 138/7D000000
primary_streaming_lag | 0
standby_streaming_lag | 338
-[ RECORD 3 ]---------+----------------------------------------------
application_name      | <application_name>
current_wal_lsn       | 138/7D054AF8
last_sent_wal         | 138/7D054AF8
last_replay_wal       | 138/7D000000
primary_streaming_lag | 0
standby_streaming_lag | 338

primary_streaming_lag and standby_streaming_lag values are in KB as it’s divided by 1024. This is nice but it’s only available on primary node. If we are experiencing lag on a standby node, it can mean that this node is under heavy load or network latency. It’s important to monitor replication directly on standby nodes. And so, Repmgr has its own table to monitor replication.

select * from repmgr.replication_status;

-[ RECORD 1 ]-------------+----------------------------------------------
primary_node_id           | 1
standby_node_id           | 3
standby_name              | <application_name>
node_type                 | standby
active                    | t
last_monitor_time         | 2019-11-22 11:07:51.673005+01
last_wal_primary_location | 143/4C009390
last_wal_standby_location | 143/4C009390
replication_lag           | 0 bytes
replication_time_lag      | 00:00:00
apply_lag                 | 0 bytes
communication_time_lag    | 00:00:00.960348
-[ RECORD 2 ]-------------+----------------------------------------------
primary_node_id           | 1
standby_node_id           | 4
standby_name              | <application_name>
node_type                 | standby
active                    | t
last_monitor_time         | 2019-11-22 11:07:51.100838+01
last_wal_primary_location | 143/4C0091D0
last_wal_standby_location | 143/4C0091D0
replication_lag           | 0 bytes
replication_time_lag      | 00:00:00
apply_lag                 | 0 bytes
communication_time_lag    | 00:00:01.532515
-[ RECORD 3 ]-------------+----------------------------------------------
primary_node_id           | 1
standby_node_id           | 2
standby_name              | <application_name>
node_type                 | standby
active                    | t
last_monitor_time         | 2019-11-22 11:07:51.310996+01
last_wal_primary_location | 143/4C0092B0
last_wal_standby_location | 143/4C0092B0
replication_lag           | 0 bytes
replication_time_lag      | 00:00:00
apply_lag                 | 0 bytes
communication_time_lag    | 00:00:01.322357

This view is created and available on each node, primary and standby. You can check how this view is built on Repmgr Github, depends your Repmgr version.

Furthermore, Repmgr offers a check service by node.

/usr/bin/repmgr -f /etc/repmgr.conf node check

Node "<application_name>":
    Server role: OK (node is standby)
    Replication lag: OK (0 seconds)
    WAL archiving: OK (10 pending archive ready files)
    Downstream servers: OK (this node has no downstream nodes)
    Replication slots: OK (node has no physical replication slots)
    Missing physical replication slots: OK (node has no missing physical replication slots)
    Configured data directory: OK (configured "data_directory" is "<data_directory>")

Replication lag checks if the node is lagging by more than replication_lag_warning and replication_lag_critical parameters. By default, it’s 300 and 600 ms.

A big thanks to Karen and Marc Barret for their time and proofreading.

Photo by Jan Kolar / VUI Designer on Unsplash

How to see and limit memory consumption of an application ?

Victor Gallet — Wed, 24 Jul 2019 21:45:47 +0000

For a few months, my computer experienced some freezing during several minutes and the only solution to return to work was a reboot. It’s really annoying so I decided to look at what’s going on.
I have been working since three years on a laptop DELL E7450. It has 8GB RAM size and an Intel i5 core with 2 cores and 4 logical processors. It is quite enough to work with, isn’t it ?
I’m using Ubuntu 18.04 coupled with i3 for my window manager. By the way, if you don’t know yet about i3, you have to take a look at it.
I noticed that with only 2 open applications : Google Chrome and Slack, both used most of my memory. Google Chrome is well known to use a lot of RAM and Slack application is built upon Electron and bad news: Electron is a known resource hog.

Memory Usage

I’ve made some simple tests to check memory consumption. As you can see from this picture, only 2 open applications use nearly 100% of my memory.

This picture is extracted from a screenshot of the htop program. Htop is a great alternative to top. It provides facilities to filter, sort, search and view per core. The thing that interested me here is the memory, especially memory per process. To do that, i’m using smem, a tool that calculates the USS, PSS and RSS per process.

USS stands for Unique Set Size. This is the amount of unshared memory unique to that process. It does not include shared memory. In the other hand, PSS stands for Proportional Set Size. It adds together the unique memory (USS), along with a proportion of its shared memory divided by the number of processes sharing that memory. It gives a representation of how much actual physical memory is being used per process - with shared memory truly represented as shared.

RSS stands for Resident Set Size. This is the amount of shared memory plus unshared memory used by each process. If any process shares memory, this will over-report the amount of memory actually used, because the same shared memory will be counted more than once - appearing again in each other process that shares the same memory. This metric can be unreliable, especially when processes have a lot of forks.

Here the command I used :



smem -n -s pss -t -k -P chrome

If you're not familiar with command line, you can use explainshell.com, a great website to dissect commands.

To sum up, 57 processes match ‘chrome’ and used 4,9G of USS, 5.0G of PSS and 7,7G of RSS.

Let’s focus on Slack memory consumption:

Memory Limitation

Let’s say I want to limit the memory allocated to the Slack application. My first thought was to use Docker. By wrapping the application in a Docker container, I can use Docker abilities to limit the resources of a container.

For example:



docker run --memory=1G ….

This parameter will set the maximum amount of memory the container can use. It works, but it means I need to create a Docker image dedicated to all applications I want to limit the amount of memory.
In fact, Docker uses a technology called namespaces to isolate containers from other processes. To learn more about Docker architecture, you can take a look at Docker overview page. One namespace is interesting in my case : Control groups also known as cgroups. This one enables the limitation of physical resources.

Let’s use it:



# Create a group for memory named “slack_group”
cgcreate -g "memory:slack_group" -t victor:victor

# Specify memory limit to 1G for this group
cgset -r memory.limit_in_bytes=1G "slack_group"

To ensure memory limitation is correctly applied, it’s possible to look in directory /sys/fs/cgroup/memory/mygroup/ and precisely at file memory.limit_in_bytes.



# Launch slack application in this group
cgexec -g "memory:slack_group" slack

# If needed, we can remove the group
cgdelete "memory:slack_group"

In my case, I use cgroups only to limit memory allocated but it’s also possible to limit CPU.

Then, let’s see if it’s works.

As you can see, PSS is strictly equal to 1G but the swap has now increased to 500M. The application is a bit slow, changing from one workspace to another is a bit long but it’s still comfortable to use.
Let’s disable swap to see if it works.



echo 0 > /sys/fs/cgroup/memory/slack_group/memory.swappiness

Guess what ? It doesn’t work, the application is not responding and some processes are killed. In fact, it’s the OOM Killer (Out-of-memory Killer) who is in charge to kill processes in order to free up memory for the system. The OOM Killer selects the best candidate for elimination from a score maintained by the kernel. You can see this score in:



/proc/${PID}/oom_score

Automation

I know how to limit memory consumption for one application but it’s definitely not sustainable in the future. I will have to create a group per each application I want to limit memory usage. Thanks to this StackExchange question, I found a script that does the job. It’s available here:

This script creates a group each time it’s launched and remove it when it’s killed.
Easy to use:



limitmem.sh 1G slack

That’s fine but this script is a piece of code that I will have to maintain, update, upgrade, etc….

Another way to integrate memory limit to my system is to use systemd.

systemd is a Linux initialization system and service manager that includes features like on-demand starting of daemons, mount and automount point maintenance, snapshot support, and processes tracking using Linux control groups. systemd provides a logging daemon and other tools and utilities to help with common system administration tasks. Reference.

To do this, I have to wrap my application into a systemd service.



[Unit]
Description=slack
After=network.target 

[Service]
User=victor
Group=victor
Environment=DISPLAY=:0
ExecStart=/usr/bin/slack
#Restart=on-failure
KillMode=process
MemoryAccounting=true
MemoryMax=1G

[Install]
WantedBy=multi-user.target

By specifing paramaters MemoryAccounting and MemoryMax, I’m able to limit memory allocated. As explained in systemd documentation, systemd organizes processes with cgroups. In my opinion, using systemd is far more sustainable than maintaining a custom shell script as it’s became the standard for most Linux distributions.

Conclusion

As I was writing this article, slack engineering published an article announcing a new Slack desktop application and I quote:

One of our primary metrics has been memory usage

To be clear, my goal was not to prove how bad memory management is of Slack application. I simply wanted to go deeper in memory management for the operating system I use. I used slack application here like I could have used any other.

By the way, all of this makes me think: do I have to let a messaging application consumes 30% of my memory? More generally, do I have to let any application manages it own memory consumption? Could the concept of container (an application in an isolated environment) be applied to my everyday applications?

Don’t hesitate to tell me if I forgot a way to limit memory consumption and let me know what you think about it.

Thanks to Nastasia and Mathieu for their time and proofreading.

Cover photo by Harrison Broadbent on Unsplash

Dockerize your integration tests

Victor Gallet — Fri, 04 Jan 2019 09:01:38 +0000

Most of our applications have to talk to a database, a HTTP API, a message broker, a SMTP server, etc… And it's quite complicated to set up a real test environment with those components.

In some cases, we can simply mock those components or have an in-memory one during test execution. For example, H2 ou HSQLDB are in-memory databases well-known for being used during integration tests. However, they are not the one used in production environment and our tests can seem unrepresentative.
Today, it's possible to use all the power of Docker and set up a connected test environment easily thanks to Testcontainers.

Testcontainers

Testcontainers allows us to easily manipulate Docker containers during test execution. It uses the Docker client docker-java to communicate with Docker daemon. It works with most operating systems and environments and despite the best-efforts support for Windows, I use it on a daily basis with Docker Toolbox. You can find the matrix compatibility here.

When you create a container, Testcontainers will try to connect to the Docker daemon by using DOCKER_HOST, DOCKER_TLS_VERIFY and DOCKER_CERT_PATH variables. These environment variables can be easily overridden in the JVM for example.

Create a container

Containers are represented with the object GenericContainer. It's possible to create a container from an image, a Dockerfile or from a Dockerfile created on the fly. In addition, it's possible to create containers from a Docker Compose file.
For instance, this is an Elasticsearch server created from the image docker.elastic.co/elasticsearch/elasticsearch:6.1.1.

GenericContainer container = new GenericContainer("docker.elastic.co/elasticsearch/elasticsearch:6.1.1")
   .withEnv("discovery.type", "single-node")
   .withExposedPorts(9200)
   .waitingFor(
      Wait
       .forHttp("/_cat/health?v&pretty")
       .forStatusCode(200)
   );

We can see that it's fairly easy to provide environment variables to the container with the method withEnv. In this case, it's the variable discovery.type with value single-node.
Next, we make sure that our container is up by making an HTTP call on /_cat/health API and having a 200 code response. There are also other strategies to assert a container is running:

Wait.forLogMessage waits for a log message,
Wait.forListeningPort waits for a listening port
Wait.forHealthcheck enables to use HEALTHCHECK feature from docker.

To finalize the container configuration, our container is exposing internal port 9200 and this is explicitly set with the method withExposedPorts. It means that Testcontainers will map this container's port to a random port. It's possible to retrieve mapped port with the method getMappedPortotherwise we can define port bindings with the method setPortBindings. Here, we expose the port 9200 from our container to port 9200:

container.setPortBindings(Arrays.asList("9200:9200"));

That's it! Our Elasticsearch server is ready to be used. To start it up, we simply have to execute the start method:

container.start();

At startup, Testcontainers will run a bunch of checks like the docker version or the connection to the registered Docker Registry. This can be blocking if you are working behind a company proxy, so it's possible to disable those checks by creating the file testcontainers.properties in the tests resources directory with this content:

check.disable=true

At last, we can stop our container with the method stop.

container.stop();

This will stop the container and also remove the attached volume. This is great because it prevents having dangling volumes.

During Tests

One great strength of Testcontainers is its integration with JUnit framework. In fact, GenericContainer objects are JUnit rules. It means that their lifecycle is directly bound to the test lifecycle. Thereby, by using the @Rule or @ClassRule JUnit annotations, our containers will be initialized before the test start-up and stopped at the end of the tests execution.

@ClassRule
public static GenericContainer redis = new GenericContainer("redis:3.0.2")
               .withExposedPorts(6379);

Nevertheless, it means that Testcontainers will come with a JUnit 4 dependency and it can be annoying if your tests run with JUnit 5. Indeed, JUnit has replaced the Rule concept with Extension. Since the version 1.10.0 released on November 2018, Testcontainers supports now JUnit 5 and it's possible to use extensions with the help of @Testcontainersand @Container annotations from the dedicated library junit-jupiter:

<dependency>
 <groupId>testcontainers</groupId>
 <artifactId>junit-jupiter</artifactId>
 <version>1.10.2</version>
</dependency>

Preconfigured container

Like Docker, Testcontainers ecosystem is very rich. You can find preconfigured containers like MySql, PostgreSQL, Oracle database, Kafka, Neo4j, Elasticsearch, etc.

@Rule
public KafkaContainer kafka = new KafkaContainer();

You can browse the list directly from maven repository.

A concrete case

Let's see a concrete example of using Testscontainers with the Spring PetClinic application. It's a demonstrating project based on several Spring components like Spring Boot, Spring MVC and Spring JPA. This application aims at managing a pet clinic with pets, pet owners and vets.

The controller layer exposes HTTP endpoints to create and read entities. Then, the persistence layer communicates with a relational database. The application can be configured to communicate with a HSQLDB or a MySql database.

The persistence layer is tested with integration tests and those uses an in-memory HSQL database while the persistence layer itself uses a MySql database.

Requirements

First, we have to install Docker on the machine which is going to execute tests. Then, we need to add the Testcontainers dependency to the project. In this case, we simply add the following to the pom.xml file:

<dependency>
  <groupId>org.testcontainers</groupId>
  <artifactId>testcontainers</artifactId>
  <version>1.10.2</version>
  <scope>test</scope>
</dependency>

Database configuration

The default database configuration is done in the application.properties file.

database=hsqldb
spring.datasource.schema=classpath*:db/${database}/schema.sql
spring.datasource.data=classpath*:db/${database}/data.sql

As we can see, this is an in-memory HSQLDB database initialized with a schema from the schema.sql file. Then, the database is populated with the data.sql file. This is the default project configuration.
We need to create application-test.properties file to configure a connection to a MySql database.

spring.datasource.url=jdbc:mysql://localhost/petclinic
spring.datasource.username=petclinic
spring.datasource.password=petclinic
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

Next, let's take the test class ClinicServiceTests.java. This class contains all integration tests for the persistence layer. First of all, we need to change Spring test configuration to ensure that the tests will use our database connection.

The @TestPropertySource annotation enables to load our file application-test.properties and @AutoConfigureTestDatabase with the NONE value prevents Spring from creating an embedded database.

MySql container

Let's create a MySql database that matches requirements from our tests. In this instance, we use the ability from Testcontainers to create a Docker image from a Dockerfile created on the fly. As a first step, we have pulled a MySql official image from Docker Hub:

Now, we have to create our database and the connection's user. This is done by using environment variables from the Docker image.

Next, we have to create a database schema and populate the database. From the image documentation, the directory /docker-entrypoint-initdb.d is scanned at startup and all files with .sh, .sql et .sql.gz extension are executed. So, we just have to put our files schema.sql and data.sql in this directory.

By using withClasspathResourceMapping, the files schema.sql and data.sql are put on the classpath into the container as a volume. Then, we can access it into our Dockerfile construction.
One last thing, we have to expose the default MySql port: 3306.

Unfortunately, we can't directly set port bindings with the method setPortBindings. We have to customize the container on creation with the method withCreateContainerCmdModifier. Finally, we are waiting for the listening port to ensure that our container is up.
Voilà! With few lines of code, we have easily set a MySql database for our tests without having to manage the container lifecycle. The @ClassRule annotation makes our container starting once for all the tests. You might be wondering: have we extend the test execution time? In fact, it only takes 907 ms with a Docker container against 860 ms with a HSQLDB in-memory database. The source code shown in this section is available on github.

A big thanks to Sonyth, Sebastien, Laurent, Louis and Nicolas for their time and proofreading.

Builder Pattern, a first step to DSL

Victor Gallet — Wed, 05 Dec 2018 19:13:09 +0000

When you are looking for an explanation of Builder pattern, you will probably find some articles all showing a class dedicated to creating an object. It's quite simple and we can go deeper with this pattern.

Let's start from the beginning with the class Person below:

public class Person {

   private String firstname;

   private String lastname;

   private String nickname;

   private String email;

   private String gender;

   private String country;

   private String city;

   public Person(String firstname, String lastname, String nickname, String email, String gender, String country, String city) {
       this.firstname = firstname;
       this.lastname = lastname;
       this.nickname = nickname;
       this.email = email;
       this.gender = gender;
       this.country = country;
       this.city = city;
   }
}

As we can see from this piece of code, there will be problems when creating a new Person object:

constructor that's too big,
constructor parameters have all the same type. We have to remember the right order of each parameter when using it. In fact, we are façing a common code smell: primitive obsession. You can take a look at this article which explains how to recognize and deal with them.
How can we set up constraints? It can be difficult to check nullity or to ensure consistency between fields.

So to deal with some of these points, we can add several constructors. For example:

public Person(String firstname, String lastname) {
   this(firstname, lastname, null, null, null, null, null);
}

public Person(String firstname, String lastname, String nickname) {
   this(firstname, lastname, nickname, null, null, null, null);
}

public Person(String firstname, String lastname, String nickname, String email) {
   this(firstname, lastname, nickname, email, null, null, null);
}

By adding different constructors to our class Person, the result is that building responsibility is delegated to the client. The developer who wants to create an object Person has to know which constructor to use and why. Moreover, the resulting code is difficult to read and to understand :

Person john = new Person("john", "smith", "john");

In this simple piece of code, it's difficult to know where the first name, last name, and nickname parameters are. We have to go through the source code to check on which fields will be initialized. An handy solution is to create a builder class to address this readability problem.

public class PersonBuilder {

   private final Person person;

   private PersonBuilder() {
       person = new Person();
   }

   public static PersonBuilder builder() {
       return new PersonBuilder();
   }

   public PersonBuilder withFirstname(String firstname) {
       if (firstname == null) {
           throw new IllegalArgumentException("firstname must be not null");
       }
       person.setFirstname(firstname);
       return this;
   }

   public PersonBuilder withLastname(String lastname) {
       if (lastname == null) {
           throw new IllegalArgumentException("lastname must be not null");
       }
       person.setLastname(lastname);
       return this;
   }

  ...

   public Person build() {
       return person;
   }
}

Then, we can use it like this:

Person john = PersonBuilder.builder()
   .withFirstname("john")
   .withLastname("smith")
   .build();

Great! This solution has the benefit of explicit arguments. We can easily understand what person's first name is. In addition, it was easy to add a not-null constraint for each building method. Furthermore, as each method returns the instance of PersonBuilder, it provides us a pseudo DomainSpecificLanguage.

However, unlike a constructor, this builder is not self-explanatory and can be used incorrectly. For example:

Person john = PersonBuilder.builder()
    .build();

This simplest case reveals a lack of guidance. In fact, it's possible to guide the developer during the creation phase.
For example, let's say we want to divide the creation process into four steps:

the developer has to set the first name first,
then he can set the last name,
then he can set the email
and finally he can build a Person object.

To do this, we have to create four interfaces :

public interface StepFirstnameBuilder {

   StepLastnamePersonBuilder withFirstname(String firstname);
}

This first step enables the developer to set the first name field and then to use the second step interface StepLastnamePersonBuilder.

 public interface StepLastnamePersonBuilder {

   StepEmailPersonBuilder withLastname(String lastname);
}

public interface StepEmailPersonBuilder {

   FinalStepPersonBuilder withEmail(String email);
}


public interface FinalStepPersonBuilder {

   Person build();
}

Finally, after setting all mandatory fields we can access the build method.
That's it! Now we can modify PersonBuilder class to implement our four steps.

public class PersonBuilder implements StepFirstnameBuilder, 
StepLastnamePersonBuilder,
StepEmailPersonBuilder,
FinalStepPersonBuilder {


   private final Person person;

   private PersonBuilder() {
       person = new Person();
   }

   public static StepFirstnameBuilder builder() {
       return new PersonBuilder();
   }

   @Override
   public StepLastnamePersonBuilder withFirstname(String firstname) {
       if (firstname == null) {
           throw new IllegalArgumentException("firstname must be not null");
       }
       person.setFirstname(firstname);
       return this;
   }

   @Override
   public StepEmailPersonBuilder withLastname(String lastname) {
       if (lastname == null) {
           throw new IllegalArgumentException("lastname must be not null");
       }
       person.setLastname(lastname);
       return this;
   }

   @Override
   public FinalStepPersonBuilder withEmail(String email) {
       person.setEmail(email);
       return this;
   }

   @Override
   public Person build() {
       return person;
   }
}

Now, let's use it:

Person john = PersonBuilder.builder() // -> returrns an instance of StepFirstnameBuilder
   .withFirstname("john") // -> returns an instance of StepLastnamePersonBuilder
   .withLastname("smith") // -> returns an instance of StepEmailPersonBuilder
   .withEmail("john@smith.com") // -> returns an instance of FinalStepPersonBuilder
   .build();

By implementing all these steps, we have totally controlled the way a Person object is built. Actually, we have just created a DomainSpecificLanguage. This Builder pattern is a particular case of FluentInterface dedicated to building object and it's an easy way to express the way an object is built.

A big thanks to Sonyth and Mickael for their time and proofreading.

Migration from Junit 4 to Junit 5

Victor Gallet — Mon, 23 Apr 2018 07:25:29 +0000

While working on my current project, I got some time to migrate from JUnit 4 to JUnit 5.
Since JUnit 5 was released in September 2017, it's the right time to take a look at it.

My application is a java 8 maven project divided into 7 maven modules and each module has it owns integration and unit tests. However, one of these modules is dedicated to tests. It contains all the test needed dependencies and it's injected as scope test into others modules.
Our tests dependencies are the most common in a Java project. We use JUnit 4, AssertJ, Mockito, DbUnit and Spring Test.

At last, we also have a dedicated project to run end-to-end testings based on Selenium, Fluentlenium and JGiven.
Unfortunately, JGiven does not fully support JUnit 5. It's currently in an experimental state, so I haven't started this migration.

Dependencies

Let's start by adding the new JUnit dependencies :

<dependency>
   <groupId>org.junit.jupiter</groupId>
   <artifactId>junit-jupiter-engine</artifactId>
   <version>${junit.version}</version>
</dependency>
<dependency>
   <groupId>org.junit.vintage</groupId>
   <artifactId>junit-vintage-engine</artifactId>
   <version>${junit.version}</version>
</dependency>
<dependency>
   <groupId>org.junit.platform</groupId>
   <artifactId>junit-platform-launcher</artifactId>
   <version>${junit.platform.version}</version>
</dependency>
<dependency>
   <groupId>org.junit.platform</groupId>
   <artifactId>junit-platform-runner</artifactId>
   <version>${junit.platform.version}</version>
</dependency>

The important to take note of is the import of junit-vintage-engine. It provides the ability to run JUnit 4 tests and JUnit 5 tests simultaneously without difficulty.

Unit Tests

The next step is to replace all imports of old JUnit annotations by the newest.

import org.junit.Test

become

import org.junit.jupiter.api.Test;

Here's the mapping of each annotation:

JUnit 4	Junit 5
org.junit.Before	org.junit.jupiter.api.BeforeEach
org.junit.After	org.junit.jupiter.api.After
org.junit.BeforeClass	org.junit.jupiter.api.BeforeAll
org.junit.AfterClass	org.junit.jupiter.api.AfterAll
org.junit.Ignore	org.junit.jupiter.api.Disabled

As we use AssertJ for all our assertions, I didn't need to migrate JUnit 4 assertions.

Rules

One the biggest change is the removal of the concept of rules, that has been replaced by extension model. The purpose of extension is to extend the behavior of test classes or methods and it replaces JUnit runner and Junit Rules.

One rule that we all have used is ExpectedException and it can be easily replaced by JUnit assertThrows :

   @Test
    void exceptionTesting() {
        Throwable exception = assertThrows(IllegalArgumentException.class, () -> {
            throw new IllegalArgumentException("a message");
        });
        assertEquals("a message", exception.getMessage());
    }

Another well-known rule to migrate is TemporaryFolder. Unfortunately, JUnit 5 does not provide a replacement yet. There is an open issue in Github.

Introduce a TemporaryFolder extension #1247

sbrannen posted on Jan 18, 2018

Overview

See discussion at https://github.com/junit-team/junit5-samples/issues/4.

Related Issues

#219

Deliverables

[X] ~~Introduce an official TemporaryFolder extension for JUnit Jupiter analogous to the rule support in JUnit 4.~~

View on GitHub

So what can we do to make it work?

First of all, it's possible to keep tests using those rule in JUnit 4 thanks to junit-vintage-engine.

Another solution is to continue to use JUnit 4 TemporaryFolder rule by adding the dependency junit-jupiter-migrationsupport.

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-migrationsupport</artifactId>
    <version>${junit.version}</version>
</dependency>

This module enables to run JUnit 5 tests with rules. For example :

@EnableRuleMigrationSupport
public class JUnit4TemporaryFolderTest {

    @Rule
    public TemporaryFolder temporaryFolder = new TemporaryFolder();

    @Test
    public void test() throws IOException {
        temporaryFolder.newFile("new_file");
    }
}

However, this feature only supports :

rules that extend org.junit.rules.ExternalResource
rules that extend org.junit.rules.Verifier
rule ExpectedException and it's currently marked as experimental so use it at your own risk.

Finally, one solution is to create our own TemporaryFolderExtension based on Junit 4 implementation.

public class TemporaryFolderExtension implements BeforeEachCallback, AfterEachCallback {

   private final File parentFolder;
   private File folder;

   public TemporaryFolderExtension() {
       this(null);
   }

   public TemporaryFolderExtension(File parentFolder) {
       this.parentFolder = parentFolder;
   }

   @Override
   public void afterEach(ExtensionContext extensionContext) {
       if (folder != null) {
           recursiveDelete(folder);
       }
   }

   @Override
   public void beforeEach(ExtensionContext extensionContext) throws IOException {
       folder = File.createTempFile("junit", "", parentFolder);
       folder.delete();
       folder.mkdir();
   }

   public File newFile(String fileName) throws IOException {
       File file = new File(getRoot(), fileName);
       if (!file.createNewFile()) {
           throw new IOException("a file with the name \'" + fileName + "\' already exists in the test folder");
       }
       return file;
   }

   public File newFolder(String folderName) {
       File file = getRoot();
       file = new File(file, folderName);
       file.mkdir();
       return file;
   }

   private void recursiveDelete(File file) {
       File[] files = file.listFiles();
       if (files != null) {
           for (File each : files) {
               recursiveDelete(each);
           }
       }
       file.delete();
   }

   public File getRoot() {
       if (folder == null) {
           throw new IllegalStateException("the temporary folder has not yet been created");
       }
       return folder;
   }

}

This implementation does not fully support all extension features like Parameter Resolution but at least, it allows us to fully migrate our tests to JUnit 5.
In addition, it's possible to inject extensions as rule by using @RegisterExtension

@RegisterExtension
public TemporaryFolderExtension temporaryFolder = new TemporaryFolderExtension();

This annotation enables us to build an extension with parameters and to access is during test execution.

Custom Rules

In my case, I had only one custom rule to migrate. Its goal is to create an in-memory SMTP server for asserting sending emails.

public class SMTPServerRule extends ExternalResource {

   private GreenMail smtpServer;
   private String hostname;
   private int port;

   public SMTPServerRule() {
       this(25);
   }

   public SMTPServerRule(int port) {
       this("localhost", port);
   }

   public SMTPServerRule(String hostname, int port) {
       this.hostname = hostname;
       this.port = port;
   }


   @Override
   protected void before() throws Throwable {
       super.before();

       smtpServer = new GreenMail(new ServerSetup(port, hostname, "smtp"));
       smtpServer.start();
   }

   public List<ExpectedMail> getMessages() {
       return Lists.newArrayList(smtpServer.getReceivedMessages()).stream()
           .parallel()
           .map(mimeMessage -> ExpectedMail.transformMimeMessage(mimeMessage)).collect(Collectors.toList());
   }

   @Override
   protected void after() {
       super.after();
       smtpServer.stop();
   }
}

To make it work as a JUnit extension, it only needs to implement BeforeEachCallback and AfterEachCallback interfaces instead of inheriting from ExternalResource. The main implementation is still the same.

public class SMTPServerExtension implements BeforeEachCallback, AfterEachCallback {

   private GreenMail smtpServer;
   private String hostname;
   private int port;

   public SMTPServerExtension() {
       this(25);
   }

   public SMTPServerExtension(int port) {
       this("localhost", port);
   }

   public SMTPServerExtension(String hostname, int port) {
       this.hostname = hostname;
       this.port = port;
   }

   public List<ExpectedMail> getMessages() {
       return Lists.newArrayList(smtpServer.getReceivedMessages()).stream()
           .parallel()
           .map(mimeMessage -> ExpectedMail.transformMimeMessage(mimeMessage)).collect(Collectors.toList());
   }


   @Override
   public void afterEach(ExtensionContext extensionContext) throws Exception {
       smtpServer.stop();
   }

   @Override
   public void beforeEach(ExtensionContext extensionContext) throws Exception {
       smtpServer = new GreenMail(new ServerSetup(port, hostname, "smtp"));
       smtpServer.start();
   }

Integration Tests

Next, I had to update Spring integration tests and it was quite easy as class SpringExtension is included in Spring 5.

@RunWith(SpringJUnit4ClassRunner.class)

become

@ExtendWith(SpringExtension.class)

Mockito Tests

Let's continue with tests that use Mockito. Like we have done with Spring integration tests, we have to register an extension :

@RunWith(MockitoJUnitRunner.class)

become

@ExtendWith(MockitoExtension.class)

In fact, class MockitoExtension is not provided by Mockito yet and it will be introduced with Mockito 3.
One solution is the same as TemporaryFolderExtension...that is to keep our tests in JUnit 4. However, it's also possible to create our own extension and so Junit team give one implementation of MockitoExtension in its samples.
I decided to import it into my project to complete my migration.

Remove JUnit 4

Then, to ensure all my tests run under JUnit 5, I checked if there is any JUnit 4 dependency by executing :

mvn dependency:tree

And so, I had to exclude some of them :

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>junit</groupId>
                    <artifactId>junit</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.dbunit</groupId>
            <artifactId>dbunit</artifactId>
            <version>${dbunit.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>junit</groupId>
                    <artifactId>junit</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Maven

Last but not least, I needed to update the maven surefire plugin to make it works with JUnit 5.

<!--
        The Surefire Plugin is used during the test phase of the build lifecycle to execute the unit tests of an application.
        -->
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>${maven-surefire-plugin.version}</version>
            <dependencies>
                <dependency>
                    <groupId>org.junit.platform</groupId>
                    <artifactId>junit-platform-surefire-provider</artifactId>
                    <version>1.1.1</version>
                </dependency>
                <dependency>
                    <groupId>org.junit.jupiter</groupId>
                    <artifactId>junit-jupiter-engine</artifactId>
                    <version>${junit.version}</version>
                </dependency>
            </dependencies>
        </plugin>

Be careful with the version of your maven surefire plugin as the 2.20 has a memory leak. JUnit documentation suggests the version 2.21.

Conclusion

This migration was really easy, but even so, JUnit 5 is totally different from JUnit 4. In the end, I was able to remove the import of junit-vintage-engine as I don't have Junit 4 test anymore. I only regret the fact that I had to create my own temporary folder extension and Mockito extension.
Finally, it's possible to get more help with your migration by consulting Junit5-samples.

A big thanks to Sonyth, Mickael and Houssem for their time and proofreading.

CNC2018 5 Blog ideas

Victor Gallet — Tue, 30 Jan 2018 14:45:05 +0000

CNC2018 Blog More - Mission 1

Hey guys, I'm currently involved in #BlogMore challenge from CNC2018.

My first mission is to look for ideas and to validate them. Here are my five ideas, let me know what's on your mind :

How I created custom JUnit annotations for Elasticsearch integration tests. It's a simple example of how you can create custom annotations to set up test fixtures in Java.
What’s new in the next release of Chrome DevTools.
A summary of my first time at Snowcamp, a French technical conference.
A feedback on how we do high availability and continuous delivery in my current project. It will be about all technologies involved in the process of development, validation, delivery of a web application and also interactions between people.
How to set up a simple Elasticsearch search and autocompletion mechanism into your legacy application. It's will be in Java.

Thank for your feedback and don't hesitate to ask me precision.