Unit Testing with jbang

[maxandersen]

I've been pondering how to go about writing unit tests for jbang scripts/apps.

There are two parts afaics, one on how the tests look like the other how to run them.

The first part on how they look like I think is fairly straight forward now we have //SOURCES feature.

i.e. if you have script looking like:

///usr/bin/env jbang "$0" "$@" ; exit $?

class helloworld {

    String greeting(String who) {
          return "Hello " + who;
    }

    public static void main(String[] args) {
        helloworld hw = new helloworld();

        if(args.length==0) {
            System.out.println(hw.greeting("World"));
        } else {
            System.out.print(hw.greeting(args[0]));
              
        }
    }
}

Then the most basic test of that would be:

//DEPS org.junit.jupiter:junit-jupiter-engine:5.2.0
//DEPS org.hamcrest:hamcrest-library:2.1

//SOURCES helloworld.java

import java.io.PrintWriter;

import org.junit.jupiter.api.Test;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.equalTo;

public class TestLauncher {

    @Test 
    void testGreeting() {
        helloworld hw = new helloworld();
        assertThat(hw.greeting("me"), equalTo("Hello me"));
        assertThat(hw.greeting(null), equalTo("Hello"));
    }
}

This setup actually works (kinda) today and you can use idea with jbang edit TestLauncher and you can run the tests just fine directly from the ide.

I'm wondering how/if we should add some native test support to jbang to make it easier.

i.e. jbang unittest TestLauncher.java could generate what corresponds to:

jbang org.junit.platform:junit-platform-console-standalone:1.7.0 --classpath 'jbang info classpath testscript.java' --scan-classpath

where jbang info classpath generates the classpath.

then junit 5 test runner would find all identifiable tests and run them.

Could also just tell users to run the above command but a) its quite long and b) it won't work on windows.

Ideas/thoughts on testing with jbang?

[OLibutzki]

My thoughts:

I don't use a CI server to build my scripts continuously. So when to run the tests?

What about linking the test classes in the script file itself?

When you run the script the tests are executed first and the script is only executed if the tests pass.

You need to add some convenience stuff like caching the results if the class under test did not change or skipping tests explicitly, but this is my first take on this.

[OLibutzki]

could be; but again no real way to check if a test is 100% dependent on just the code could also be dependent on external changes.

Taking about a unit test, I assume that the test results only depend on the test class and the class under test. If both don't change, the test should always return the same result.

Otherwise bayou would get into trouble with your run tests before pushing approach as you don't know if the script breaks right after running tests because of some external changes.

I always run my tests locally before I push to a CI server...I assume same applies here for the scripts.

Like a CI server it's just an additional safety net. Of course the developer should execute the tests before pushing the changes.

Instead of linking the test classes from the script one could think about a naming convention, but in my opinion it's ok that the script knows its tests as they act as a kind of specification.

Regarding convenience:

• cache test results if test classes and classes under test didn't change

Add options to

• skip test execution
• run script regardless of test results
• force test execution although classes did not change

[maxandersen]

If both don't change, the test should always return the same result.

you are assuming those who write jbang scripts with tests will have done so perfectly all knowing and with all mutating state mocked away... I think that is pretty unrealistic to assume is the case for all users :)

what is the point of "run script regardless of test results" ?
what is the value of running the tests to then just run the script ?

[OLibutzki]

you are assuming those who write jbang scripts with tests will have done so perfectly all knowing and with all mutating state mocked away... I think that is pretty unrealistic to assume is the case for all users :)

Yes, that's my assumption and my understanding of what a unit test is all about.

what is the point of "run script regardless of test results" ?

The default flow could be:
(if tests are present && at least one class is changed since last test run) run tests -> (if tests ran successfully) run script

You need some jbang options to overrule the default flow:

• skip tests
• run script although at least one test failed
• force test execution although no classes changed since last test execution

Of course one could also think about another default flow which does not execute any tests by default. Then you need to specify explicitly explcitly from the command line that you want to execute the tests.

[helpermethod]

Something like executable examples would be desirable (similar to doctest in Python).

https://byexamples.github.io/byexample/languages/java

[quintesse]

@helpermethod I wanted to point out that we have support for running MarkDown files, which would be very similar, I think, to what you linked to: https://www.jbang.dev/documentation/guide/latest/usage.html#running-markdowns-md-experimental

But I see that part of the documentation is completely wrong (basically just a copy&paste from the previous section). So we need to fix that first. (See #1239)

[kenyee]

Would also be nice to have a template with unit tests for a JBang script w/ multiple source files as an example.

[albertocavalcante]

Just wondering if there's a current recommendation / best practice regarding this.

[maxandersen]

for now there is jbang init -t junit yourscript.java which will create a yourscriptTest.java that will setup a test for it.

still not liking that i have to but that much scaffolding code in place to run junit but didn't find a better way (yet)

[maxandersen]

Another one I realize is possible given junit-team have a jbang catalog.

jbang cli@junit-team execute  --scan-classpath -cp `jbang info classpath <yourtests>`

that yourtests can be anything runnable by jbang, but for this usecase a myTest.java which depends on jars and/or sources with what you want to test.