JavaScript function read from another feature file using callonce in Background fails on second test

[nathanchilton]

TL;DR

A regression has occurred in 1.1.0.RC4. We do not see this problem in 1.1.0.RC3.

If we read a .feature file containing JavaScript functions, using callonce in the Background of another .feature file. We find that the second Scenario to call the JavaScript function encounters the following error:

not a callable feature or js function

Example Code

I put together the simplest way of reproducing the problem that I could.
A JavaScript function is defined in common.feature:

Feature: Common Functions

    Scenario: Define something to be used elsewhere
        * def greeter = function(name){ return 'Hello ' + name.first + ' ' + name.last + '!' }

Then, in tests.feature, we bring in that JavaScript function using callonce in the Background:

Feature: Two tests, using JavaScript function via another .feature file

    Background:
        * callonce read("common.feature")

    Scenario: Call JavaScript function defined in another feature file
        * call greeter {first: "John", last: "Doe"}

    Scenario: Call JavaScript function defined in another feature file a second time
        * call greeter {first: "Jane", last: "Doe"}

It works for the first Scenario and fails for the second (and any subsequent Scenarios).

karate-1.1.0.RC4_regression.zip

More Details

The pattern we are using for most of our tests is to call a "setup" .feature file in the Background section, which defines common JavaScript functions and Java objects which we use to determine the hostnames and ports of resources for a test environment in Kubernetes (new namespaces, with unique names are created multiple times per day).

For tests which require authentication, we handle all of the authentication when calling this .feature file, so we use callonce in the Background, so that we only need to sign in once, for all of the tests in that .feature file. We can resolve this error, by using call instead of callonce, but that would mean signing in for each test.

I suppose we might be able to separate out the JavaScript functions from the .feature file that handles authentication, but I really want to keep things as simple as possible for my QA Analysts. (Actually, the setup.feature file does not contain the JavaScript functions, but reads them in from elsewhere.) We are also working toward getting our developers to help with writing Karate tests, and I want to keep things as simple as possible for them, too.

[ptrthomas]

@nathanchilton I think it is fixed and will close since this is an "interim" version and is releated to #1558 and #1633

it would be great if you can build locally and validate: https://github.com/intuit/karate/wiki/Developer-Guide

[nathanchilton]

@ptrthomas, I was able to build Karate from the develop branch and confirmed that the issue is fixed, both for my simplified test case, and (more importantly) for our real tests! Thank you! That was fast!