Kotest support

[abendt]

hi folks,

in a previous project i have used fluentlenium in combination with Kotest (https://kotest.io/). Kotest is a testframework for kotlin.
i recently took some time to cleanup the code and to extend it to the different Kotest testing styles (https://kotest.io/docs/framework/testing-styles.html).

would you generally be interested to add this to the fluentlenium project?

• GitHub project: https://github.com/abendt/kotest-fluentlenium
• check https://github.com/abendt/kotest-fluentlenium#writing-tests for test examples

[slawekradzyminski]

Short answer - yes :)

Would you try to add separate module as a PR? Is it easy to migrate into Maven?

[abendt]

cool :-)

sure, migration to maven should be straightforward

[christian-draeger]

Not related to kotest but to Kotlin in general:
I am currently experimenting with some funky dsl Functions as extensions for fluentlenium in kotlin.
Here some example usage: https://github.com/christian-draeger/basic-selenium-project/blob/master/src/test/java/tests/browser/BrowserTestExampleIT.kt

If there is general interest of having something like this included in fluentlenium just let me know :) even if it currently is just a small POC, I am pretty sure that using the capabilities kotlin is giving us here could help to write even more readable tests with fluentlenium in kotlin :)

Would you be interested to have a kotlin dsl module added as well (or maybe a kotlin module with all kotlin related stuff)?

[slawekradzyminski]

@christian-draeger is it something related to KoTest or separate extension? Sorry, I'm not great with Kotlin, I've only used Espresso in this language :)

[christian-draeger]

hey @slawekradzyminski ,
it's not related to kotest directly but deals with kotlin support in general - thereby it would clearly be another extension, smth like 'fluentlenium-kotlin-dsl' - but would help to make test written with kotest look even more sexy since it also uses a DSL-ish approach.

just as short intro:
Domain-specific languages, or DSLs, are languages specialized for a specific part of an app. It is used to extract a part of the code to make it reusable and more understandable. As opposed to a function or a method, DSLs also change the way you use and write code. Usually, DSLs make the code more readable, almost like a spoken language. This means that even people who don’t understand the architecture behind the code will be able to grasp the meaning of it - which is especially of interest when it comes to testing imho. the easier to read the better. It removes a lot of boilerplate code and hide the internal implementation from the user. One of the best examples is a crucial part of Android development (since you mentioned espresso) – Gradle.

Finally, one could claim its only syntactic sugar, but it clearly helps to increase readability and plays really well with the idea to have a fluent interface for selenium :)

here a short example that compares classical approach (java style) with a dsl style prototype i wrote:

    @Page
    lateinit var page: StartPage

    @Test    
    fun `an example test using page object pattern`() {
        goTo(page)
        assertThat(page.loginButton).isDisplayed
        assertThat(page.loginButton.text()).isEqualTo("Sign in")
        assertThat(jq("footer a")).hasSize(36)
    }

    @Test    
    fun `an example test using page object pattern via dsl`() {
        goTo(page)
        page {
            loginButton {
                assert {
                    it.isDisplayed
                    it hasText "Sign in"
                }
            }
            "footer a" {
                assert {
                    it hasSize 36
                }
            }
        }
    }

The power of it is that its still totally regular kotlin code, which means you can just put whatever code like if conditions, loops, calculations or other method calls etc in between, which is a big benefit over the java builder pattern for instance.

good examples how far one could go with kotlin DSLs:

• gradle
• spring-fu/kofu
• skrape{it}
• kotlinx.html
• ktor
• ...

if you would be open to provide a kotlin DSL extension just let me know - i can open a PR :)

[slawekradzyminski]

I see no problems with adding it, would you like me to release initial fluentlenium-kotest module first or should I wait for your PR with fluentlenium-kotest-dsl and then release those 2 new modules?

I need to add a few things into docs but generally speaking release is almost ready 😄

[christian-draeger]

ah no, don't let the kotest users wait 🙂
i think i will take some days to think about different cases etc.
the kotlin dsl module can be released later on since it has no dependencies or something to the kotest module. it will just play well together if someone is using them both in the future but the dsl will also work in junit (like in the given example) as well as in any other environment / standalone.

[slawekradzyminski]

@abendt guess we should update the docs at least slightly (and main README). Is this something you can do? :)

[abendt]

@abendt guess we should update the docs at least slightly (and main README). Is this something you can do? :)

yes, i can do that

created a first PR that contains a kotest example: #1262

this adds some doc: #1263

[abendt]

@slawekradzyminski could you provide some information how the docs work?

which files do i need to edit? .md .html?

[slawekradzyminski]

Looks perfect :) docs will be released when I merge new release to master

[slawekradzyminski]

@abendt give me some time with release because mvn -Pjava11 release:prepare fail for unknown reasons :(

You can also help me debug why it's not working (I assume that's one of the newly bumped libraries). Here is full release guide btw:
https://github.com/FluentLenium/FluentLenium/tree/develop/dev-config

[abendt]

will have a look

[abendt]

what i did:
checkout develop
run mvn -Pjava11 release:prepare -Dresume=false
answer the questions about the version numbers (e.g. 4.6.3 and 4.6.4-SNAPSHOT)

then the build fails with this message:

   [ERROR] Failed to execute goal on project fluentlenium-testng: Could not resolve dependencies for project org.fluentlenium:fluentlenium-testng:jar:4.6.3: org.fluentlenium:fluentlenium-core:jar:4.6.3 was not found in https://repo.maven.apache.org/maven2 during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]

is this what you mean or something different?

[abendt]

what maven version are you using?

[slawekradzyminski]

Same error here on every maven version I tried.

I don’t understand why it builds submodules using release version. It should first build snapshot and change poms later :(

[abendt]

when running the command mvn -Pjava11 release:prepare -Dresume=false the build fails with the error message seen here: https://gist.github.com/abendt/94d27114e534a1a2389d4ae950525094

looking at the output it seems its not executing all maven phases for the core module
https://gist.github.com/abendt/94d27114e534a1a2389d4ae950525094#file-gistfile1-txt-L125-L134
I do not understand why this is happening.

Next i changed the configuration of the maven-release-plugin thereby overwriting the arguments coming from the parent pom:

<configuration>
                     ...
                    <arguments>-Dfoo=bar</arguments> <-- HERE
                 </configuration>

this results in a different command executed during release:prepare: [INFO] Executing: /bin/sh -c cd /Users/pho/Projects/FluentLenium && /opt/local/share/java/maven3/bin/mvn -s /var/folders/_4/3px8nr_x243399h66bkn08j00000gn/T/release-settings10781522706218553316.xml clean verify --no-plugin-updates -Dfoo=bar -P java11 (compare with the original one here https://gist.github.com/abendt/94d27114e534a1a2389d4ae950525094#file-gistfile1-txt-L76)

This runs successfully!

The difference is the profile -Psonatype-oss-release. Not sure where this Profile is supposed to be defined? Also it seems weird that an absent profile has such an impact on the lifecycle execution of the maven build

[abendt]

that profile is defined here: https://github.com/sonatype/oss-parents/blob/master/oss-parent/pom.xml#L107

[abendt]

this also allows to reproduce the issue w/o release:

mvn -Psonatype-oss-release verify

[abendt]

the profile apparently adds three plugins to the build. i tried to add the plugins directly to the parent pom. with the javadoc plugin i could reproduce the issue:

 <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <version>2.7</version>
                <executions>
                    <execution>
                        <id>attach-javadocs</id>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

Upgrading the maven-javadoc-plugin version seems to fix that issue

[abendt]

another suggestion is to add a github action that runs the release step with dryMode: https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#dryRun

this could help to catch incompatible changes related to the maven-release-plugin earlier

[abendt]

i have created another PR that should provide a workaround by upgrading the maven-javadoc-plugin to the latest version

[slawekradzyminski]

@abendt should I run this:

mvn -Pjava11 release:prepare -Dresume=false

Or this

mvn -Pjava11,sonatype-oss-release release:prepare -Dresume=false

Thanks for help :)

[abendt]

mvn -Pjava11 release:prepare -Dresume=false

Or this

mvn -Pjava11,sonatype-oss-release release:prepare -Dresume=false

i think the first one should be enough.

when doing a release:prepare the configuration from the parent pom (check maven-release-plugin here) will already add the argument that will enable the profile:

                        <arguments>${arguments} -Psonatype-oss-release</arguments>

[abendt]

adding the profile manually is just useful to test the behavior without actually starting a maven release

[slawekradzyminski]

I'm uploading the jars now :)

[slawekradzyminski]

I gave up for now. There is explicit requirement to have javadoc in each module (source). I don't know how we released Spock module before.

I created a ticket, let's see how it goes.

https://issues.sonatype.org/browse/OSSRH-70223

[abendt]

try to change the classifier from groovydoc to javadoc

[slawekradzyminski]

Good tip, looks better:)

[slawekradzyminski]

Released v4.8.0

[slawekradzyminski]

Please share with Kotliners :D

https://www.linkedin.com/posts/slawekradzyminski_release-java-11-480-fluentleniumfluentlenium-activity-6810947274936528896-oVql

[slawekradzyminski]

https://fluentlenium.com/docs/test-runners/#kotest

[abendt]

@slawekradzyminski can we close this ticket now?

i announced this release in the kotest slack. there was a question about a kotlin DSL. @christian-draeger if you are still up to work on that i suggest to open a new ticket here and move the discussion there. i can then also link that ticket to the slack question.