1

I have an architectural problem, as I am wondering how to structure my features. I will give an example what I want to achieve, without code duplication.

-scenarios
--directoryA
---feature1
----scenario1
----scenario2
--directoryB
---feature2
----scenario3
Feature1: Users

@create_user
Scenario1: Create a User
* url 'someUrl'
Given request `somerequest`
When method post
Then status 201
And match response == { id: #uuid }
* def userId = response.id

@create_user_key
Scenario2: Create a User key
* url 'someUrl'
* def createUser = call read('this:users.feature@create_user')
Given path 'userId', 'keys'
When method post
Then status 201
And match response == { key: #string }
* def userKey = response.key
Feature2: Tokens

Scenario3: Create token
* url 'someUrl'
* def createUser = call read('classpath:scenarios/directoryA/feature1.feature@create_user_key')
* def userHeader =
"""
function() {
   return "Bearer " + userKey
}
"""

Given path 'userId', 'tokens'
And header Authorization = userHeader
When method post
Then status 201

As far as I know, it is suggested Scenario1 and Scenario2 to be in a separate file. Here comes my question:

I need both Scenario1 and Scenario2 in order Scenario3 to be executed (userId and userKey are needed). If I call Scenario2, where should I store values in order to avoid code duplication?

I am aware that Scenario does not store values, but I do not want to create Background with Scenario1 and Scenario2 in Feature2, when these are stored in another feature. It doesn't matter whether it's a one scenario per feature or more.

Thanks

1 Answers1

1

Take some time and read this section of the documentation very carefully: https://github.com/intuit/karate#calling-other-feature-files - and then read the section on "Shared Scope".

Short answer - you can "return" variables from a called feature. I don't see the problem, after the call - you can start using variables from createUser like this (or refer to it directly by path):

* def userId = createUser.userId

All this said - I will caution you that you appear to have gotten into the trap of attempting "too much reuse" - a common problem with teams doing test-automation. Yes, sometimes "reuse is bad" - it is okay if you don't believe me - but this needs to be said. For an example, please read this answer: https://stackoverflow.com/a/54126724/143475

Peter Thomas
  • 54,465
  • 21
  • 84
  • 248