3

I am trying to call a feature file, which is also calling another one inside. The feature I am calling is in another directory. Therefore, when I execute the scenario it is looking in the wrong place.

Here is an example:

-scenarios
--directoryA
---feature1
---feature2
--directoryB
---feature3

Feature: feature2

  Scenario: scenario2
    * url testUrl
    * def testCall = call read('feature1.feature')

    Given request { test: 'test' }
    When method post
    Then status 201

Feature: feature3

   Scenario: scenario3
   * url testUrl
   * def testCall = call read('classpath:scenarios/directoryA/feature2.feature')

   Given request { test: 'test' }
   When method post
   Then status 201

The error I get after feature 3 is executed:

feature2.feature:9 - javascript evaluation failed: read('feature1.feature'), java.io.FileNotFoundException: /Users/svetoslavlazarov/project/src/test/java/scenarios/directoryB/feature1.feature (No such file or directory)

The problem here is that call for feature1 is in wrong directory. It should look at directoryA, instead of directoryB. However, if I execute the scenario2 standalone, it is fine.

Can you help me with this? Thanks.

Solar Field
  • 45
  • 6

1 Answers1

4

Try this:

* def testCall = call read('this:feature1.feature')
Peter Thomas
  • 54,465
  • 21
  • 84
  • 248
  • 1
    It works when I add this. Thanks for the answer, Peter Thomas! Can you give some insights how this works in this case? :) – Solar Field Jul 08 '19 at 18:48
  • @SolarField `this` is actually an un-documented feature because I believe you shouldn't be doing too much of nested feature calls :) `this` means that it is relative to the "current" feature file. – Peter Thomas Jul 08 '19 at 19:25
  • @Adrien it should – Peter Thomas Jul 09 '19 at 11:44
  • Is reducing code duplication really considered a bad thing? DRY. – Keith Tyler Jan 26 '22 at 00:18
  • @KeithTyler yes - especially in the context of test-automation: https://stackoverflow.com/a/54126724/143475 – Peter Thomas Jan 26 '22 at 06:04
  • @PeterThomas Thanks for sharing. I followed the link to Google, which also says: "Note that the DRY principle is still relevant in tests; for example, using a helper function for creating value objects can increase clarity by removing redundant details from the test body." It's not a black-and-white, either-or principle. Anyone who has dealt with a test corpus of any noteable size will be well familiar with the maintenance headaches that code redundancy inevitably presents. There is a simple solution: DRYer refactoring. I would argue that 2 levels of modularization is far from being excessive. – Keith Tyler Jan 27 '22 at 00:39
  • @KeithTyler sure. totally up to you. I have a point of view based on experience seeing teams re-use in the context of Karate. there is of course no "right answer" and "it depends" – Peter Thomas Jan 27 '22 at 03:09