DEV Community: Artem Ptushkin

Gitlab python-based job to remove stale branches

Artem Ptushkin — Mon, 15 Jul 2024 07:54:22 +0000

Problem

GitLab has a concept of stale branches, where they defined all the branches updated more than 3 months ago as stale.

However, it's not possible to do a bulk removal or have a more sophisticated control of these branches.

Here is a full example of how you can set this up. As for scheduled tasks you can use Gitlab scheduled jobs.

Code

How to configure DNS caching timeout in a Spring Boot docker image?

Artem Ptushkin — Tue, 26 Mar 2024 15:30:53 +0000

JVM build used for this article eclipse-temurin:21-jdk:

openjdk 21.0.2 2024-01-16 LTS
OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode, sharing)

We must differentiate JVM Security properties and System properties.

Security properties:
- can not be affected directly by the command line
- accessed with class java.security.Security
- can be modified through the file -Djava.security.properties=/java-additional.security
System properties
- can be affected directly by the command line
- accessed with class java.lang.System

Important to know:

Default value of the property is 30 (seconds) and can be found in sun.net.InetAddressCachePolicy#DEFAULT_POSITIVE
This class reads the property once during the class initialization in the static method - this is important for further conclusions
How to debug: open java.net.InetAddress line ~1141 cachePolicy = InetAddressCachePolicy.get(); and call the code InetAddressCachePolicy.get() through the debug execution

Initial options to set the value:

Security property networkaddress.cache.ttl (through the file)
System property sun.net.inetaddr.ttl (through JVM command line)

Technical in JVM it's possible to set a value in runtime (e.g. System.setProperty or Security.setProperty but this is misleading here's why:

You don't know when a property will be accessed by any code. You must either determine that you set it before other code accesses it or there is a risk that it will be not applied.

Therefore, to mediate the risk and the checks we should set the value as JVM startup parameters (not runtime).

Let's consider 3 typical build setups:

fat jar
Spring Boot docker build
Goole jib

Fat jar

There are plenty of options on how to set a JVM property, one example

Security properties with Gradle example

# gradle.properties
org.gradle.org.gradle.jvmargs="-Djava.security.properties=/your/path/java-additional.security"

Security properties with Googe Jib plugin

# build.gradle.kts
jib {
    extraDirectories {
        paths {
            path {
                setFrom("java-additional.security")
                into = "/etc/java-additional.security"
            }
        }
    }
    container {
        jvmFlags = listOf("-Djava.security.properties=/etc/java-additional.security/java.security")
    }
    from {
        image = "eclipse-temurin:21-jre"
    }
}

You can reproduce the same code with other build tools and with the Dockerfile too.

Event this is not enough

Spring uses Apache HTTP client underneath and by default connection TTL there is infinite. You can change it to (see):

@Bean
    fun poolingHttpClientConnectionManager(): PoolingHttpClientConnectionManager =
        PoolingHttpClientConnectionManagerBuilder
            .create()
            .apply {

                setDefaultConnectionConfig(ConnectionConfig
                    .custom()
                    .setTimeToLive(TimeValue.ofMinutes(30))
                    .build()
                )
            }
            .build()

// which you set to 

HttpClients.custom().setConnectionManager(poolingHttpClientConnectionManager)

Handle Gitlab pipeline duplication

Artem Ptushkin — Mon, 19 Jun 2023 11:04:27 +0000

Problem

There is a known problem that in Gitlab it's not possible to avoid pipeline duplication in some scenarios.

Context

Let's assume you combine merge and branch pipelines. You can follow the Gitlab guideline or here is an improved one:

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "web"'
    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
      when: never
    - if: '$CI_COMMIT_BRANCH'

When you push and then you open a MR immediately it's not possible to avoid getting a second pipeline (though if you have one open then it's not an issue).

Solution with git options

See Gitlab CI push options

git push -o merge_request.create

This solution with the script below

Here is a script that supposed to be run after the push to cancel the duplication.

How to use?

Create an alias in your bash profile / .zshrc file, e.g.: alias cancel-branch-pipeline="sh ~/gitlab/gitlab-cancel-branch-pipeline.sh"
Set you Gitlab personal access token with scopes api and read_api as GITLAB_TOKEN environment variable (you can set it in your bash profile file to have in every session: export GITLAB_TOKEN=<your-token>)
Call it after with the alias anytime you push, and you want to open a MR: $ cancel-branch-pipeline

Best practices for writing contract tests

Artem Ptushkin — Thu, 06 Apr 2023 11:41:52 +0000

Contract testing is a broad topic that includes such areas as:

Building reliable pipeline
Framework concepts and key functionalities knowledge
Writing consumer contract tests in a scalable design and covering it on the provider side with the easily maintainable verifications

The first two points usually appear to be on the shoulders of a smaller group of people (Devops, platform engineers and team leads) but the latter one affects every developer who wants to write contract tests following the set of design patterns in his project. Here let's talk about this point.

Maturity level:

You know contract testing
You know consumer-driven contract testing
You know API
You care about the project and standards in your company
You already have written your first contract
You know how to run the provider tests and verify the consumer's contract
You focus to get as much as possible from contract tests

Writing your best contracts

1. Focus on the actual API rather than on the code

Before writing the contract test I always recommend calling the actual endpoint to see the request and response then the goal is simple - reproduce the contract in the test. You can use any tool like Postman, curl, etc.

Call the endpoint in Postman before writing the test

Why?

HTTP contract test is about HTTP semantics and you can't always see or can't find the required semantics that will be taken into the actual request effect in one place. For example:
- Authorization is not visible very often
- The base path defined in some configuration

2. Write the contract in a way it reflects the actual integration that you expect

This point comes along with the first one. Trusting a message from your colleague or your intuition and even openapi (swagger) is not enough. You should see the actual integration in front of you. If the actual endpoint doesn't exist then align the contract with your provider before the merge.

3. Be flexible in your expectations

I often find that only exact values are being used in the contract though it's not expected that API returns or expects always a constant value - it's the only case when you should use the exact value.

In all the other cases try following the robustness principle. Find more about this in this article.

The best practices for writing any part of the contract are:

Always use example value and a matcher (regex, type, date formats, etc.)

For example, this code expects that query parameter amount will be any integer but 2 as an example and an exact value in the request on the provider side :

.matchQuery("amount", ".d*", "2")

4. Use fewer constants and common components in tests

If you like and know how to write reusable code it's not necessary these patterns must be applied to any testing code. We make it worse when we write common components in tests chasing the DRY principle. It brings unnecessary cohesion to your tests thus when you change a value in a common place you break N tests instead of one.

Try using fewer constants and common components in your tests

Making tests cohesive we:

make the HTTP semantic less visible by looking at the pact code
add redundant coupling: it's not easy to play with your code changing a constant because other tests will fail using that constant value

5. Use fewer production model classes in your tests code

This point is close to the 4th and the 1st. Relying on any production code or giving credit of trust to the developer who wrote that. Though that model doesn't need to reflect 1:1 the integration, there might be in place: converts, serialisation configurations, etc. You may miss this, so it's easier just to use plain JSONs and, respecting the 3d point, library DSLs.

Relying on the production code in your tests inputs we make it difficult following the TDD pattern

Another argument, respecting the 1st point, is that you think about the code instead of the actual JSON writing the test which brings you to assumptions.

6. Always verify the contract on the provider side

The contract testing with Pact is about the consumer and provider. Writing just the pact and finishing your work you can not be a curtain that you covered the integration.

Every pact must be verified on the provider side to bind the consumer and the provider

In my experience, developers that write tests separately end up in a situation where after the merge they have to do an additional job later to align/verify the contract on the provider side. It might be very exhausting work so:

Better writing fewer tests but always verifying all of them on the provider side

7. Mock as deeper as it's possible on the provider side

tl;dr

Mock the repository level or insert it into your database in the tests

Here is a great explanation video

You might get an idea to mock the controller level and this idea is bad here is why:

All the following tests will follow the same principle because it costs a lot to restart the application for every test - no one does that, you will have the same set of beans (mocks)
You isolate the major part of your application and you simply can't get some layer that causes an exception that you need to cover a contract

More examples:

Context: in Spring Boot applications classically we have layers: controller, repository, service etc. You can mock any layer of those by mocking a bean so that a mock returns the result of the corresponding method.

Less cohesive. The mocks do not really describe a state of a system (service) rather they do a small snapshot of a layer that depends on DTO classes. It makes mocks less cohesive with tests, thus it's a high chance that tests based on mocks will pass but on practice, the example data in mocks will never appear.
Making assumptions of application behavior. Development by mocks makes developers think about exceptions rather than the actual application behavior. Imagine you want to prepare a state that your service returns 400 when the inputs are invalid. Here as well, it makes it difficult for non-owner of the provider application to write and understand the state. The provider developer relying on a mock, e.g. exception class will prepare the state assuming that the exact exception causes the issue. Though it can be any other exception, hence when something changes the exception in the production code - the test will be not reliable.
Tests as examples. Pact with consumer-driven contracts is development-by-example, and if a layer is mocked, it says nothing to the observer about the actual system behavior. You can't use the test with mock as an example because you do not know how to reproduce this layer behavior.

Conclusions

Follow TDD in your tests thinking about the API rather then the production code
Think about reusability and how others will copy your approaches in your company

I know this article contains no code examples though I have ones in this Github repository breaking-api-bad and please not do hesitate to contact me.

Kotlin Spring Boot Configuration properties best practices

Artem Ptushkin — Thu, 14 Jul 2022 14:59:55 +0000

Jump to the example if you're quite advanced in Spring already

What do we have

Working in Spring Boot stack one of the first features that every developer is taking the advantage of is Configuration Properties

Which could be configured as:

class level beans
method based beans

Basically method level beans are the same as class level but you can create N properties beans from a single class.

The properties itself can be propagated in different ways but the most common is through application properties / yaml files.

What's important about the properties that they can be:

null
defaulted

Naming

Spring follows the next conventions as for the configuration (class with beans) and configuration properties classes:

@Configuration - *Configuration.kt
@ConfigurationProperties - *Properties.kt

It's good to follow the standards from the ecosystem you use to prevent confusions as:

Properties class is not a configuration

Anti-patterns

Difference between configuration and properties

Configuration - is a class that defines beans
Properties - is a class that defines data structure to describe the application properties, e.g. to map the properties to an object

The next example is anti-pattern because spring works differently with these concepts:

@Configuration
@ConfigurationProperties
class MyProperties {
  String value;
}

Configuration properties bean must be initialised by Spring not manually

The next example is anti-pattern because configuration properties is a bean can be initialised much more naturally when it's loosely coupled with it's configuration, for instance it's a problem if you use @ConstructorBinding:

@Component
@ConfigurationProperties
class MyProperties {
  String value;
}

Standards, code consistency

The goal of the best practices is to find the golden mean. Where we expect that the data-structure represents in a neat way the mapping between the properties and the class.

default value should be located as close as possible to the field so developer can immediately see it
nullability should represent the actual necessity of the property
it should be simple
composite children fields are designed in the same way

Having all the requirements we have the next example:

Demo

Let's say we have this set of properties defined:

io.github.artemptushkin.example:
  defaultOverriddenProperty: overridden
  requiredStringProperty: required-value
  notNullListProperty: ["foo", "baz"]

it will give us the next runtime properties:

io.github.artemptushkin.example.defaultedStringProperty=default
io.github.artemptushkin.example.defaultOverriddenProperty=overridden
io.github.artemptushkin.example.requiredStringProperty=required-value
io.github.artemptushkin.example.optionalStringProperty=null
io.github.artemptushkin.example.notNullListProperty[0]=foo
io.github.artemptushkin.example.notNullListProperty[1]=baz

Key points are:

@ConstructorBinding let's us use create immutable objects
Kotlin default constructor values let us use to have default values right in place in one single line
Always initialise collections as empty by default to prevent nullable field

Summary

It's possible to write clean classes and keep them concise from one project to another and within your company.

I hope this noted helped you.

How to migrate a directory from git repository to another one preserving git history. Bitbucket example

Artem Ptushkin — Thu, 20 Jan 2022 10:20:48 +0000

Assume we migrate:

The folder2 from git@bitbucket.org:myproject/myrepo.git

  myrepo
  │   README.md
  └───folder1
  └───folder2

to git@bitbucket.org:newrepo.git

How to do this:

To make it safe, clone myrepo.git into a new directory

mkdir myrepo-folder2-migration
cd myrepo-folder2-migration

git clone 
git@bitbucket.org:myproject/myrepo.git

cd myrepo

#prevent pushing into it
git remote rm origin

Filter git history to keep only files in folder2

git filter-branch --subdirectory-filter folder2 -- --all

Clean unwanted data

git reset --hard
git gc --aggressive 
git prune
git clean -fd

It should contain only the files from folder2 in the root git directory now

Go back and prepare to work for the newrepo

cd ..

pwd
#make sure you're in myrepo-folder2-migration

Clone the empty repository

git clone git@bitbucket.org:newrepo.git

cd newrepo

Create a connection to local repository, we're going to pull from it
```
git remote add old-repo ../myrepo
```

Pull files from the old repo

git pull old-repo master --allow-unrelated-histories

Remove the connection with local
```
git remote remove old-repo
```
Push the changes to the remote origin
```
git push
```

The new remote repository should contain files from folder2 inside the root directory now.

I followed https://medium.com/@ayushya/move-directory-from-one-repository-to-another-preserving-git-history-d210fa049d4b with adjustments I found important and clear for understanding.

How to properly ignore Junit 4 in Gradle and Maven

Artem Ptushkin — Tue, 24 Aug 2021 11:11:32 +0000

Jump to the best example here for Gradle and Maven

Problem

Quite a lot of Java dependencies bring Junit 4 or Junit vintage engine as a transitive dependency.

As well as Junit vintage engine is designed to integrate 4 and 5 version, it allows to use both at the same time. When you want to finally migrate, it leads to problems such as:

Runtime issues: a junit4 class not found
A test has run, but no coverage aggregated
Not concise annotations usage

Solution

All these problems have only one proper solution:

Use one particular version of Junit to prevent misleading and misusage

Here I focus on the latest - Junit 5 version usage, hence, excluding of Junit 4.

One of the options is to ignore this dependency from a specific dependency:

testImplementation('org.springframework.boot:spring-boot-starter-test') {
    exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'  
}

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

But, it requires you to know which dependency brings unpleasant dependency for you. In this case, you can use this command to track:

./gradlew dependencyInsight --dependency "junit:junit" --configuration "testCompileClasspath"

Another option is to exclude not necessary dependencies from all the configurations. It leads you another problems such as: some library still requires Junit 4 / vintage. But, the compilation / runtime reflection errors actually only makes these dependencies visual and help to mark explicitly those Java modules, that still require on any reason to work with a legacy library.

Gradle:

Having configurations in Gradle it is easy to exclude a dependency in one particular place:

/* for all the configurations */
configurations {
  all {
    /* only junit 5 should be used */
    exclude group: 'junit', module: 'junit'
    exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
  }
}

/* for a particular test module */
configurations {
  testCompile {
  /* only junit 5 should be used */
    exclude group: 'junit', module: 'junit'
    exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
  }
  testRuntime {
    /* only junit 5 should be used */
    exclude group: 'junit', module: 'junit'
    exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
  }
}

And don't forget to leave a comment for the future!

Resume

Hope this note helped to ignore unpleased dependency and keep control over your build configuration.

Best practices on using Jackson and Lombok

Artem Ptushkin — Tue, 17 Aug 2021 11:31:25 +0000

Jump to the examples here!

Issues

In modern Java stack Lombok and Jackson are the most widely used frameworks and as those help to work with DTO there are a bunch of questions and problems might come for the library users.

There are 631 questions on StackOverflow by the search query https://stackoverflow.com/search?q=lombok+jackson on the date of writing this article.

Definitely, a major part of this is specific problems but still a huge part of questions and answers leads to high diversity of examples, annotations usage. Following which, developers spread around repositories very different sets of annotations and configurations. It leaves lack of standards and best practices.

Expectations

Annotations are uniform within different cases
Jackson serializes and deserialises objects:
- mutable
- immutable
Jackson serializes and deserialises objects of classes that are bounded by inheritance
Classes contains as less Jackson annotations as possible to keep it framework agnostic and cleaner

Implementation

Inheritance case

import lombok.RequiredArgsConstructor;
import lombok.Value;
import lombok.experimental.NonFinal;
import lombok.experimental.SuperBuilder;

@Value
@NonFinal
@SuperBuilder
@RequiredArgsConstructor
public class Card {
    String name;
    Status status;
    Balance balance;
}

import java.beans.ConstructorProperties;
import java.math.BigDecimal;

import lombok.EqualsAndHashCode;
import lombok.Value;
import lombok.experimental.SuperBuilder;

@Value
@SuperBuilder
@EqualsAndHashCode(callSuper = true)
public class CreditCard extends Card {
    BigDecimal rate;

    @ConstructorProperties({"name", "status", "balance", "rate"})
    public CreditCard(String name, Status status, Balance balance, BigDecimal rate) {
        super(name, status, balance);
        this.rate = rate;
    }
}

Verifying by simple tests:

@Test
    void itSerializes() throws Exception {
        CreditCard creditCard = CreditCard
                .builder()
                .name("The credit card")
                .rate(new BigDecimal("5.0"))
                .status(ACTIVE)
                .balance(Balance
                        .builder()
                        .id(1L)
                        .value(new BigDecimal("1000.0"))
                        .build())
                .build();

        String expectedJson = readFromFile("credit-card-serialize.json");

        String actualJson = objectMapper.writeValueAsString(creditCard);

        JSONAssert.assertEquals(expectedJson, actualJson, true);
    }

    @Test
    void itDeserializes() throws Exception {
        String inputJson = readFromFile("credit-card-deserialize.json");

        CreditCard actual = objectMapper.readValue(inputJson, CreditCard.class);

        assertEquals(new BigDecimal("5.0"), actual.getRate());
        assertEquals("The credit card", actual.getName());
        assertSame(ACTIVE, actual.getStatus());
        assertNotNull(actual.getBalance());
        assertEquals(1L, actual.getBalance().getId());
        assertEquals(new BigDecimal("1000.0"), actual.getBalance().getValue());
    }

Mutable with inheritance

import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.experimental.SuperBuilder;

@Data
@SuperBuilder
@NoArgsConstructor
public class Animal {
    private Long id;
    private String description;
}

@Data
@SuperBuilder
@AllArgsConstructor
@EqualsAndHashCode(callSuper = true)
public class Cat extends Animal {
    private Integer lives;
}

Conclusions

In order to keep your objects immutable and be in the best compliance with Jackson use annotations:

lombok.Value
java.beans.ConstructorProperties

In order to keep object creation clean in DSL style with explicit fields mapping use annotations:

lombok.experimental.SuperBuilder on both parent and children classes

CreditCard
  .builder()
  .rate(new BigDecimal("5.0"))
  .name("The credit card") //parent field
  .status(ACTIVE)
  .balance(Balance.builder()                         
           .id(1L)
           .value(new BigDecimal("1000.0"))                  
           .build())
  .build()

I believe using a standard set of annotations within your project will simplify the maintenance. Reducing the amount of dependencies such as Jackson annotation will make it framework agnostic and plain tests will help you to verify the expected behaviour without a need to run the costly, slow tests.

Focus on:

immutability
tests
uniformity

The GitHub project with examples

Best practices on Spring Cloud Kubernetes bootstrap configuration

Artem Ptushkin — Sun, 30 May 2021 13:22:30 +0000

In this article I want to show the best way to configure any Spring Cloud bootstrap properties in your application, making it the a most flexible and future-proof way.

Jump to the code here!

Microservices stack

Following or switching into more microservice architecture, most modern Spring boot applications start using one day something from Spring Cloud stack additionally due to its features and compatibility with Spring Boot stack it already has, i.e. you take the whole ecosystem.

I describe an example in this article of how neat you it is possible to integrate Spring and Spring Boot by using starters.

Along side with Spring Cloud stack, most applications start using Kubernetes as microservices orchestration service, and for this we have the growing Spring Cloud Kubernetes project.

On purpose to externalise application's properties there are two most commons ways to implement this:

k8s configmap
Spring Cloud Config server

Considering pros and cons both of these are worth to use and none is really better than another.

Definitely, stack and complexity grows with this and following the hello world approaches online developers rather implement configuration in a way that still brings problems and/or kept unclear for other developers.

One of the crucial and the most important things is enabling/disabling of configuration, as it brings the most influence to your runtime, activating or disabling beans. This is partially confirmed by Stackoverflow questions, querying:

spring configuration doesn't start: 973
spring configuration disable: 2748
and all the other questions on bean duplication / missing problems

In order to make the best out of your configuration, I'd like to show some best practices on an example with Spring Cloud Kubernetes config.

Before jumping to the example it's better to know the basis about the Spring application properties order of precedence:

application properties https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config
bootstrap properties https://cloud.spring.io/spring-cloud-commons/multi/multi__spring_cloud_context_application_context_services.html

How to configure bootstrap properties

What are the requirements to the best configuration?

It always starts in each k8s environment
It doesn't start in tests
It start's for a local application run easily when you need it

What do we know?

bootstrap properties start before application one
application in k8s cluster container fetchs data from k8s configmap only if it's enabled beforehand
application must know where to take the properties from before the load
spring.cloud.kubernetes.enabled enables all the sub-configurations
spring.cloud.kubernetes.config.enabled enables fetching configmap
kubernetes profile exists out of box and will be activated always when the application runs as a pod inside Kubernetes

Then we need:

bootstrap.yaml in resources directory containing:

spring:
  cloud:
    kubernetes:
      config:
        enabled: false
      enabled: false

bootstrap-kubernetes.yaml containing:

spring:
  cloud:
    kubernetes:
      config:
        enabled: true
      enabled: true

application.yaml or application-kubernetes.yaml containing:

spring:
  cloud:
    kubernetes:
      config:
        name: your-configmap-name
        namespace: ${KUBERNETES_NAMESPACE}

Env variable KUBERNETES_NAMESPACE can't be determined on bootstrap configuration loading as the k8s configmap won't be fetched yet. Hence, we put it into application properties.

k8s service.yaml containing:

spec:
  containers:
    env:
    - name: "KUBERNETES_NAMESPACE"
      valueFrom:
      fieldRef:
        fieldPath: "metadata.namespace"

[OPTIONAL] To make it more transparent to developers and let everyone know that kubernetes profile will be enabled I'd advice to put this profile explicitly, service.yaml. Another argument here, that if you already use SPRING_PROFILES_ACTIVE than it definitely will be clearer if you put additionally the kubernetes profile, defining all the profiles list at the same place:

spec:
  containers:
    env:
    - name: SPRING_PROFILES_ACTIVE
      value: "your-profile,kubernetes"

Conclusions

With this configuration you can easily enable k8s by activating kubernetes profile and it will disabled on any other run.

Hints

Staring common @SpringBootApplication main class with kubernetes profile we aware that
1. You might need env variable KUBERNETES_NAMESPACE
2. It uses k8s context and namespace from the one that is used in your configuration (kubectl) now

Consumer and provider binding in contract-testing

Artem Ptushkin — Mon, 22 Feb 2021 16:45:21 +0000

I believe the fact that you are using contract-testing already has brought you here.

This approach seems simple for the first look but brings new questions and discoveries upon getting into it.

One of them is the understanding of how actually the contract corresponds with the consumer and provider.

Let's consider HTTP integration as a classic one and Pact as a consumer-driven-contracts framework here but Spring Cloud Contract follows the same rules.

The contract will be always used as a stub on the consumer side and as a set of validation criteria on the provider side

How does it affect me?

Each time you run consumer contract tests, it uses the contract data to start on it a stub server with expectations on a request and prepared stub data for response.

Each time you run provider tests, it uses the contract test to build a request to your actual server. Then it verifies the actual response against a set of validation criteria in the contact.

What's actually might be interesting here is to get an understanding of the concept of the strictness of the request/response data.

Request

Consider, you expect that a server accepts your authorization header with a Bearer JWT token.

Speaking without code: I expect when my app calls you with any valid JWT token you respond 200

Header:
  Authorization: Bearer eyJraWQiOiJ0aGlzLWlzLXJ

Consumer

You might not care about the strictness of the request data, i.e. you can use a stub that expects: any JWT bearer token

It means that matters only the format of data and not the data itself.

Provider

The request must be strict otherwise, the framework won't be able to build an actual request.

Options:

Framework generates a random value
Consumer prepare an example that will be used as a strict value

Having random values can be viable for some cases, but it leaves uncertainty as the example, that comes with the contract, will be non-informative.

In other words, the data of the request is crucial technically. And it is better to keep it strict as opposed to random.

That's why Pact framework has this option to provide the example for any data or not, btw.

Response

Vice versa for the response.

The consumer must receive strict values in the response from the stub server.

The provider can respond with something that matches some data by a patter.

	request	response
consumer	not	strict
provider	strict	not

The reference in the contract

That's when you put the expectations like this:

.matchHeader("Authorization", "Bearer.*", "Bearer eyJraWQiOiJ0aGlzLWlzLXJ")

Where the second parameter is the regexp that you expect to match the header.

It will be converted in the pact to the scrict values:

"request" {
  "method": "GET",
  "path": "/your/path",
  "headers": {
          "Authorization": "Bearer eyJraWQiOiJ0aGlzLWlzLXJ"
    }
}

Plus matchingRules that come from the regexp property we passed above:

"matchingRules": {
          "header": {
            "Authorization": {
              "matchers": [
                {
                  "match": "regex",
                  "regex": "Bearer.*"
                }
              ],
              "combine": "AND"
            }
...

Having the table above and the pact you can link them now and refer to this in your investigations.

	request	response
consumer	matchingRules	strict values
provider	strict values	matchingRules

Thinking about the format and data it is also right to consider it like this:

	request	response
consumer	format	data
provider	data	format

Sure, don't forget that for 'data' you can use random values.

Conclusions

Here I'd like to remind you that contract testing is the testing by the example approach. Thus, if you pay attention to the examples and understand the logic behind them, it will help you to have a great set of request/response samples that you can share with your teammates in combination with tests.

For more reference about the strict request and loose response read about Robustness principle.

I think one of the most important parts of understanding contract testing is the behavior of stubs and verifications. Hope this note can help you to think through this concept.

PS. I wrote about the contract testing approach here. Please join for more.

How does Jacoco work with Sonar?

Artem Ptushkin — Tue, 29 Dec 2020 11:05:45 +0000

This pair of frameworks: Jacoco+Sonar is very popular in the Java stack applications. Despite it most of Gradle/Maven files look unclear and it can take time to figure out how it is configured for the arbitrary repository.

I would like to clarify it with the schema to give developers a chance not to spend time on some things while working on a question about code coverage.

Where:

Rectangle - files as inputs and outputs
Rhombus - Gradle/Maven commands
Circle - external soft/jars

Hope it helps you to sort out the process!

How to build jdbc url to Google SQL instance?

Artem Ptushkin — Thu, 25 Jun 2020 13:36:44 +0000

I find it pretty tricky and not transparent on how to build JDBC URL to Google SQL Database instance.

Postgresql example placeholder:

jdbc:postgresql:///{database_name}?socketFactory=com.google.cloud.sql.postgres.SocketFactory&cloudSqlInstance={connection_name}:{instance_id}

You can find drivers at github to setup connection

Hope it helps!

DEV Community: Artem Ptushkin

Gitlab python-based job to remove stale branches

Problem

Code

How to configure DNS caching timeout in a Spring Boot docker image?

Fat jar

Security properties with Gradle example

Security properties with Googe Jib plugin

Event this is not enough

Links

Handle Gitlab pipeline duplication

Problem

Context

Solution with git options

This solution with the script below

How to use?

Best practices for writing contract tests

Maturity level:

Writing your best contracts

1. Focus on the actual API rather than on the code

2. Write the contract in a way it reflects the actual integration that you expect

3. Be flexible in your expectations

4. Use fewer constants and common components in tests

5. Use fewer production model classes in your tests code

6. Always verify the contract on the provider side

7. Mock as deeper as it's possible on the provider side

More examples:

Conclusions

Kotlin Spring Boot Configuration properties best practices

What do we have

Naming

Anti-patterns

Difference between configuration and properties

Configuration properties bean must be initialised by Spring not manually

Standards, code consistency

Demo

Summary

How to migrate a directory from git repository to another one preserving git history. Bitbucket example

How to properly ignore Junit 4 in Gradle and Maven

Problem

Solution

Gradle:

Resume

Best practices on using Jackson and Lombok

Issues

Expectations

Implementation

Inheritance case

Mutable with inheritance

Conclusions

Best practices on Spring Cloud Kubernetes bootstrap configuration

Microservices stack

How to configure bootstrap properties

Conclusions

Hints

Consumer and provider binding in contract-testing

Request

Consumer

Provider

Response

The reference in the contract

Conclusions

How does Jacoco work with Sonar?

How to build jdbc url to Google SQL instance?