It is impossible to mock exisiting local function in declarative pipeline

[grzegorzgrzegorz]

Hi,
Given is the pipeline which contains function inside the simpleDeclarativePipeline.pipeline file:

pipeline {
    agent { node { label 'test1' } }
    stages {
      stage('sdfsdf') {
        steps {
          githubNotify status: 'PENDING', context: 'Pipeline'
            runFunc()
        }
      }
    }
  }

  def runFunc(){
      echo "inside runFunc"
      doSomeStuff()
  }

When runFunc is mocked:

void setUp() throws Exception {

        baseScriptRoot = 'unit-testing-jenkinsfile'
        scriptRoots += 'src/main/groovy'
        scriptExtension = 'pipeline'

        super.setUp()

        helper.registerAllowedMethod("runFunc")
        helper.registerAllowedMethod("githubNotify", [Map.class], null)

    }

    @Test
    void should_execute_without_errors() throws Exception {
        def script = runScript("simpleDeclarativePipeline.pipeline")
        printCallStack()
        assertJobStatusSuccess()
    }

Then mocked function is not executed but real one instead and thus exception is thrown:
groovy.lang.MissingMethodException: No signature of method: simpleDeclarativePipeline.doSomeStuff() is applicable for argument types: () values: []

When runFunc inside pipeline is deleted:

 pipeline {
    agent { node { label 'test1' } }
    stages {
      stage('sdfsdf') {
        steps {
          githubNotify status: 'PENDING', context: 'Pipeline'
            runFunc()
        }
      }
    }
  }

Then runFunc is mocked as expected.

I tried newest version of JenkinsPipelineUnit: 1.13

This is a problem for me as I have very rich local functions I want to mock during pipeline testing. I do not want to mock functions like doSomeStuff in the example.
If this is a bug - do you know any workaround for this issue ?

[nestoracunablanco]

Hi @grzegorzgrzegorz I've taken a look at this issue, I found it interesting :)
The problem seems to be somewhere in the interceptClassMethods method in the InterceptingGCL class. A pull request will come in the next couple of minutes. A workaround until is released could be:
helper.registerAllowedMethod("runFunc", [], {})

[grzegorzgrzegorz]

Thanks for the tip @nestoracunablanco. This workaround solves the problem for function without arguments. However, my pipeline actually contains function with 2 arguments:
runFunc("p1", "p2")
in such a case I am unable to mock it and these attempts are running real runFunc with doSomeStuff function :
helper.registerAllowedMethod("runFunc", [String, String], {})
helper.registerAllowedMethod("runFunc", [String.class, String.class], {})
It is unclear to me which of above invocations is correct. Maybe all are wrong ? Could you please comment on this scenario as well?

[nestoracunablanco]

Hi @grzegorzgrzegorz I just made a change in order to be compatible with functions with more arguments. Since it uses dynamic compilation, is less performant, so let's check what @nre-ableton says about it.

[nre-ableton]

I'm not sure of the use-case here, but I don't see mocking local functions as something that would be a widely-used feature in JenkinsPipelineUnit. I would suggest either mocking the calls inside these functions (doSomeStuff, in the case of your example), or breaking out these functions to libraries where they can be easily mocked.

That said, I reviewed #510 independent of this discussion.

[grzegorzgrzegorz]

Hi, I have very different pipelines. Some of them have local functions, some of them use libraries. This is valid use case as sometimes there is no point in turning function into library if it is not used anywhere else. Sometimes, there are local functions which should become libraries but this is TODO status - I have to have working tests for such functions.

Anyway, in the spring I created my own testing framework as I just need to have tool which is useful for me. It took ma around 1 month but now I have full control of the functionality and so on... Using metaclass mocking and binding is sufficient to mock everything I need: steps, functions, objects, sections, properties, loading libraries, testing libraries. I also have something which I called emulators: aside of mocking, I can emulate steps and sections to work during the test like if they were run in Jenkins: SH, CHECKOUT etc. with default or user defined implementation. Workspace is also supported.

So to all who need to test your pipeline: try to start writing your own simple framework as Groovy metaprogramming is not so difficult. You will then decide for yourself which use case is valid and it will always suite your needs best.

[lemeurherve]

@grzegorzgrzegorz do you intend to publish your framework by any chance? Curious to see it for potential inspiration 🙂

[mcascone]

I have what I think is a similar problem/question. It has stood in my way for years at this point.

Say I have a class in vars/:

// vars/myFunction.groovy
def call() {
	childCall() 
}

def childCall() {
	// do stuff that i don't want to unit test
}

In my JPU tests, I can not find a way to mock childCall(). It will always run the real code.

class myFunctionTests extends BasePipelineTest {
  def myFunction

  @Before
  void setUp() {
    super.setUp()
    myFunction = loadScript("vars/myFunction.groovy")

	// none of these work
    helper.registerAllowedMethod('childCall', [], {})
	helper.registerAllowedMethod('myFunction.childCall', [], {})
	helper.registerAllowedMethod('call.childCall', [], {})

 @Test
 void myTest () {
	myFunction()

	assert stuff
  }
}

No matter how i try to mock childCall(), it always runs the real code, and i run into problems when that inner code exectutes.

One thing I have noticed is in the stack trace, the childCall is not listed:

  myFunction.call()
      myFunction.aSuccessfullyMockedExternalFunction()
	 // childCall() should be listed here, but it's not, and instead childCall's real code is executed
      pipelineBuild.aFunctionInsideChildCall()
myFunctionTests: localFunction: FAILURE

Is there any way to mock functions that are defined in the same vars/ code?

Thanks in advance!

[nestoracunablanco]

Hi @mcascone I just took a look at this issue. This is somewhat interesting to me :)
While I am taking a look at the code, here is a workaround that applies in your case:

class myFunctionTests extends BasePipelineTest {
  def myFunction

  @Before
  void setUp() {
    super.setUp()
    helper.registerAllowedMethod('childCall', [], {})
    helper.registerAllowedMethod('myFunction.childCall', [], {})
    helper.registerAllowedMethod('call.childCall', [], {})
    myFunction = loadScript("vars/myFunction.groovy")
}

 @Test
 void myTest () {
	myFunction()

	assert stuff
  }
}

I will let you know if I find a working solution.

[nestoracunablanco]

Making a quick analysis, I think I know the root cause of the problem. InterceptingGCL defines the methodInterceptor.
This methodInterceptor will be called every time a method is missing or invokeMethod class is called. But here is the catch: invokeMethod is not always called when a method is invoked. The language developers provide a solution for it, implementing the GroovyInterceptable interface, but as far as my investigation went the script class do not implement it by default.
Given the circumstances, I see for now this options here:

• Check if this can be fixed at language level implementing this GroovyInterceptable interface in the Script class.
• In registerAllowedMethod: calling interceptClassMethods immediately after. (But I ignore the side effects it could cause).

[mcascone]

Thanks for this @nestoracunablanco, I'm not sure how to read the bits about changing it in the JPU library, but I'll try the workaround in my tests ASAP!