add unit tests for #159

[stefanlack]

Is your feature request related to a problem? Please describe. related to #159.

Describe the solution you'd like After the pr #161 is merged, we should investigate to implement a simple unit test that tests the new code. Therefore, the logic that extracts the buildId shoul be extracted to a new method. This method can be tested afterwards through junit test, maybe with spock.

Describe alternatives you've considered

• Test the whole pipeline in jenkins. Bad. time-consuming
• Use https://github.com/jenkinsci/jenkinsfile-runner - nice, but tests more features than i actual want in this case, still time-consuming.
• Copy-Paste-And-Modify code to local groovy script. Not so good, error-prone

Additional context See Groovy Class that was used for testing to far:

class GroovyExamples {
    static void main(args) {
        v2("be-main",'build "be-main-1" started')
        v2("be-main","build.build.openshift.io/be-main-667")
    }

    private static void v2(String componentId, String startBuildInfo) {
        println("* Tests with componentId=$componentId, startBuildInfo=$startBuildInfo")

        String buildId
        def startBuildInfoHeader = startBuildInfo.split('\n').first()
        def match = (startBuildInfoHeader =~ /${componentId}-[0-9]+/)
        if (match.find()) {
            buildId = match[0]
        } else {
            buildId = startBuildInfo.split(' ').first().split('/').last()
        }
        println "buildId=$buildId";

    }
}

[clemensutschig]

@metmajer - whats your thoughts on this?

@renedupont - can you pick this one up .. we need this for ods 3 .. preferrably earlier :)

[metmajer]

@stefanlack Thanks for considering adding tests. Hopefully, tests will be part of every contribution in the future 👍 If you get to extract the changeset in #161 into a dedicated function, the fact that the code only depends on the inputs makes it sufficiently and rather easily unit-testable.

I am unaware of the potential range of input values, but since you only check for the existence of componentId in the first line of a (potential) multi-line string, the only risk I see is that you do not consider cases where the componentId is provided on a different line (if those exist at all). The rather generic error message in case of failure is not clear about this assumption.

@renedupont I'll be happy to give you an introduction to the testing framework we have set up over at https://github.com/opendevstack/ods-mro-jenkins-shared-library, which uses the Spock testing framework. In order to test a shared library code in isolation, you would need to extract it into a package within the src/ folder first. This is because Jenkins jobs inside vars/ depend on a context that cannot be easily mimicked for unit testing.

[renedupont]

@clemensutschig yes I can pick this up and will come back to @metmajer soon regarding the introduction

[metmajer]

@stefanlack this as a good learning issue for @renedupont to commence writing automated tests for this library. Therefore, I re-assign this task to him.

[stefanlack]

@metmajer , @renedupont thank you for taking this!

[renedupont]

While restructuring some code and adding the JenkinsPipelineUnit Framework with Spock I also extracted that code to its own method and added this test: https://github.com/opendevstack/ods-jenkins-shared-library/blob/master/test/groovy/org/ods/build_service/OpenShiftServiceSpec.groovy#L13

See full PR #202