Forem: Rafał Garbowski

AssertJ custom representation of asserted object

Rafał Garbowski — Sat, 17 Jun 2023 10:13:38 +0000

I really enjoy asserting collections with AssertJ.
Usually it's safer and simpler to use containsExactlyInAnyOrder rather than asserting individual elements (collection.get(0)) - even if there is only one element, because it may change in the future.
The challenge starts when asserting collection containing complex objects, because constructing an entire object as expected element can be tedious.
To extract only certain properties, we can use .extracting(Foo::field1, Foo::field2).

        var players = List.of(
            new Player("Michael Jordan", new Team("Bulls")),
            new Player("Kobe Bryant", new Team("Lakers")));

        assertThat(players)
            .extracting(Player::name, player -> player.team().name())
            .containsExactly(
                tuple("Michael Jordan", "Bulls"),
                tuple("Kobe Bryant", "Lakers"));

However, I tend to concatenate properties to string because I wasn't fond of working with tuples:

        assertThat(players)
            .extracting(player -> player.name() + " | " + player.team().name())
            .containsExactly("Michael Jordan | Bulls",
                "Kobe Bryant | Lakers");

The reason is that, by default, AssertJ provides a generic "tuple" representation in the "actual" section.
When copied, this has to be manually adapted to Java code, which can be inconvenient.

For example:

Expecting actual:
  [("Michael Jordan", "Bulls"),
    ("Kobe Bryant" "Lakers")]

What I want is an "easy-to-copy" representation of the asserted object:

Expecting actual:
  [tuple("Michael Jordan", "Bulls"),
    tuple("Kobe Bryant" "Lakers")]

Fortunately, there's an easy way to globally fix this in 3 simple steps.

Define a custom representation:

class CustomAssertJRepresentation extends StandardRepresentation {

    static final CustomAssertJRepresentation INSTANCE = new CustomAssertJRepresentation();

    @Override
    protected String toStringOf(Tuple tuple) {
        return "tuple" + super.toStringOf(tuple);
    }
}

Then add it to the global configuration:

public class CustomAssertJConfiguration extends Configuration {

    @Override
    public Representation representation() {
        return CustomAssertJRepresentation.INSTANCE;
    }

    @Override
    public String describe() {
        return "CustomAssertJConfiguration applied";
    }
}

Lastly, register the global config in this file: /src/test/resources/META-INF/services/org.assertj.core.configuration.Configuration which will contain:

my.package.CustomAssertJConfiguration

Refer to the official documentation for more information: https://assertj.github.io/doc/#assertj-core-representation

Introducing safe-eyes-cli: strict break reminder based on YAD

Rafał Garbowski — Sat, 08 Apr 2023 16:33:07 +0000

I'm excited to share with you a new tool that I've been using to help protect my eyes while working on my computer. It's called safe-eyes-cli and it's inspired by the popular Safe Eyes application.

It's a "strict" break reminder based on YAD.

A "strict break reminder program" is a software application designed to remind users to take regular breaks from their computer work. It enforces strict rules for breaks, such as locking the screen, displaying full-screen reminders, or disabling input devices during the break period. This ensures that users take breaks and rest their eyes, helping to prevent eye strain, repetitive stress injuries, and promoting overall wellbeing.

The tool is customizable, allowing to set the frequency and duration of breaks.

One of the great things about safe-eyes-cli is simplicity. It's a shell script, that anyone can easily modify and adapt for special needs. Another killer feature is that it can automatically pause during calls, so you don't have to worry about interruptions while you're on an important call.

If you're interested in trying out safe-eyes-cli for yourself, you can find it on GitHub at https://github.com/RG9/safe-eyes-cli. The installation instructions are straightforward and easy to follow.

Let me know if you have any questions or feedback!

Three ways to configure HTTP Proxy in Playwright

Rafał Garbowski — Thu, 23 Mar 2023 23:26:40 +0000

TL;DR

In fact, in Playwright v.1.31.1 there are three ways to configure an HTTP proxy:

chromium.launch
browser.newContext
page.setExtraHTTPHeaders, but works only on Firefox

Today I was struggling with proxy setup for Browserless ...

Official docs says:

Both browserless, and Chrome itself, support the usage of external proxies. In order to fully utilize a 3rd-party proxy you'll need to do two things:

-   Specify the address of where the proxy is with the `--proxy-server` switch.
-   Optionally, you'll also need to send in your username and password if the proxy is authenticated.

Ok, so I need to set --proxy-server. I was using a Docker image to run Browserless locally. I discovered that there is an environment variable called PROXY_URL:

podman run --rm -p 3000:3000 -e "PROXY_URL=my-proxy-url" browserless/chrome:latest

Fine, but how do I pass on the username and password?
Docs say there are two methods:

## Using username and password
### Method 1: page.authenticate
### Method 2: page.setExtraHTTPHeaders

I'm using playwright-java and there is no method page.authenticate, so page.setExtraHTTPHeaders left, I thought.

page.setExtraHTTPHeaders(Map.of("Proxy-Authorization", "Basic "  
   + new String(Base64.getEncoder().encode("username:password".getBytes()))));

Unfortunately, it does not work. I received the following strange error: net::ERR_INVALID_ARGUMENT. Besides there was no errors in container's logs. What's the hack?

Google's top two results for playwright Proxy-Authorization:

I quickly checked the first link. The answer says that there are two ways. I didn't read further, because I thought that I know these ways - one is method I'm struggling with and second chromium.launch, right? :) Later it turned out that I was wrong!

The second link looks like what I need. However issue was closed without any conclusion. The alternative shown, was one that I already knew:

browser = await playwright.chromium.launch(
    proxy={"server": "localhost:8080", "username": "user", "password": ""},
)

The case was that I didn't want to lanuch browser, but rather connect to one created inside container.

I dug even deeper and found another similar issue in Playwright project:
# [Feature] Directly set Proxy-Authorization in Chrome without configuring any other proxy settings

The problem (in Chrome/Chromium anyway) is that Proxy-Authorization may not be set explicitly via extraHTTPHeaders. If you do this and then try to navigate to any page Chrome will give you the following error: net::ERR_INVALID_ARGUMENT.

I was lost, considering changing my approach...

Fortunately, my teammate assisted me by showing some examples of where I found a missing piece:

Browser.NewContextOptions options = new Browser.NewContextOptions()  
   .setProxy(new Proxy("my-proxy-url")  
      .setUsername("username")  
      .setPassword("password"));  
BrowserContext context = browser.newContext(options);

Ta da! As simple as that! 😃

I checked the playwright docs and it appears to be possible:

Proxy can be either set globally for the entire browser, or for each browser context individually.

Unluckily there is no example, so it's hard to spot.

I also double-checked node.js - How do I authenticate a proxy in playwright - Stack Overflow and configuring proxy via browser.newContext was actually there, but I missed it (confused by Browserless docs?):

const browser = await chromium.launch({
    proxy: { server: 'per-context' }
});
const context = await browser.newContext({
    proxy: { server: 'http://myproxy.com:3128' }
})

Getting to the point:
Festina lente ("hurry slowly") and read comprehension!

JUnit's @CsvSource.quoteCharacter

Rafał Garbowski — Sat, 18 Feb 2023 16:40:14 +0000

@CsvSource used with text blocks is really awesome! Similarly to validation files, it can be used to create easily readable tests with readily visible inputs and outputs placed side by side.

For example:

    @ParameterizedTest
    @CsvSource(delimiterString = "->", textBlock = """
        ABC -> abc
        Abc -> abc
        """)
    void toLowercase(String input, String expected) {
        assertThat(input.toLowerCase())
            .isEqualTo(expected);
    }

What recently confused me was the following error:

org.junit.jupiter.api.extension.ParameterResolutionException:
No ParameterResolver registered for parameter [java.lang.String arg1] in method [void MyTest.test(java.lang.String,java.lang.String)].

It came out that it was caused by a parameter value starting with a single quote ', that wasn't closed by another ' at the end of value. In my case the culprit was 'S-GRAVENHAGE, which is Belgian street name.

The solution is to set parameter quoteCharacter to double quote ", provided we are using text block. This way we can test empty string with "".

Example:

    @ParameterizedTest
    @CsvSource(quoteCharacter = '\"', delimiterString = "->", textBlock = """
        'S-GRAVENHAGE -> 's-gravenhage
        "" -> ""
        """)
    void toLowercase(String input, String expected) {
        assertThat(input.toLowerCase())
            .isEqualTo(expected);
    }

I hope it was helpful, cheers!