Karate netty: Multiple feature file -m (mocks) is rolled back

[dinesh19aug]

Karate netty no longer accepts multiple feature file. This feature was added and merged in 0.9.6 as part of #1159.

In 1.0.0 FeatureServer was replaced MockServer in Main.java class and this #1281 change rolled back the feature.

Please add the option of accepting multiple feature file backs.
Diff:
-- @option(names = {"-m", "--mocks"}, description = "mock server file(s)")
-- List mocks;
++ @option(names = {"-m", "--mock"}, description = "mock server file")
++ File mock;

[ptrthomas]

this is a wontfix because it added more complexity and we re-wrote the mock from scratch. please contribute code if you want this back

[dinesh19aug]

@ptrthomas Can you please provide pointer where should I start looking? I see that FeatureServer has been replaced by MockServer. If you can just list key files that I can start with to add this change back, I can work on it.

[ptrthomas]

@dinesh19aug sure, here is an explanation on what went behind this change and thoughts on how it can be brought back: #1338

and the MockHandler is the main file: https://github.com/intuit/karate/blob/4db11f0012aa89a6de008550ce50596e0457eb06/karate-core/src/main/java/com/intuit/karate/core/MockHandler.java

when you submit a PR you can use this issue as a reference

[ivangsa]

Hi,

@ptrthomas @dinesh19aug we are also interested on multiple mock features, something simple, first feature in order that matches an scenario serves de request..

@dinesh19aug if you can help me test this https://github.com/ivangsa/karate/commits/features/mockHandler

other improvements we are interested also are configuring a prefix (or contextPath) which is already include above
and runtime-hooks for intercepting request/response which may involve a bit of work more

[dinesh19aug]

@ivangsa absolutely. I can help it test. Currently my use case is that we have lots of different Apis built by different teams. Each team wants to maintain their own folder and different feature file for every api resources.
I will take your code and test it out and will add some additional Junit as well if required. We are limited in resources so cannot have separate karte port for each Api also maintaining big feature file is not recommend as well hence need the feature back.

[ivangsa]

@dinesh19aug yes we have a similar use case, some endpoints are complex enough to go on a separate file, while others are simple and can be combined on one feature...

The refactoring is just in the MockHandler, instead of keeping just one feature/scenario-runtime variable I create a list of features/runtimes... but each are instantiated and executed just the same... everything else is just augmenting the API for passing several feature files..

[dinesh19aug]

Ok. I will test it and add comment by Friday Eod

[dinesh19aug]

@ivangsa - I verified the solution fix and able to make use of multiple feature file after creating stand alone jar. Added some code refactoring for big methods in MockHandler. Please review PR - ivangsa#1

[dinesh19aug]

@ptrthomas / @ivangsa - There is another enhancement which I think would be very useful.
Summary:
Given a directory, iterate recursively and find all the feature file. Automatically add the multiple feature file.
EX:
/Users/dinesh/karate/featureDir

• api1

  • ap1.feature
  • api1-feature1-response.json

• api2

  • ap2.feature
  • api2-feature1-response.json

Assume that -F ==> Parent Feature directory
When I start java -jar karate.jar -p 3000 -F /Users/dinesh/karate/featureDir
The karate server start up would be equivalent to
java -jar karate.jar -p 3000 -m /Users/dinesh/karate/featureDir/api1/api1.feature -m /Users/dinesh/karate/featureDir/api2/api2.feature

Let me if you see this as useful enhancement and I can create a new enhancement and start working on it. I used this feature for POC at work and it saves me tons of time instead of writing command line -m multiple time

[ptrthomas]

@dinesh19aug I'm not sure about this especially how to determine the order of finding files. I would prefer explicit and via the api.

[ivangsa]

@dinesh19aug if you can guaranty same order every time (i.e alphabetical) it should be ok as long a there is not "default" scenario..
Maybe you can reuse "--mocks" options as it is a list of File and can hold a directory as well

For me it's ok... I will merge your changes now so you can manage this on top if @ptrthomas it's ok with that

[dinesh19aug]

@dinesh19aug if you can guaranty same order every time (i.e alphabetical) it should be ok as long a there is not "default" scenario..
Maybe you can reuse "--mocks" options as it is a list of File and can hold a directory as well

For me it's ok... I will merge your changes now so you can manage this on top if @ptrthomas it's ok with that

@ptrthomas / @ivangsa - I am trying to understand why would ordering matter here? Ex - I have 10 feature files, why would ordering matter if feature file 10 is loaded before feature file 1? The code is eventually, just creating a list of scenarios from all files. If you can provide a criteria, I can provide an option load the file in order - by name(asc/desc), number of scenarios in each file or may be based on file timestamp.

@ptrthomas - Yes. You are right, currently that is what I am doing, I am using --mocks options programmatically to load all the files in directory and then creating the list of feature files. However, for command line, if your 30+ files like I have, I would not want to write -m so many times.

[ptrthomas]

@dinesh19aug fine, fine, you all can do what you want - if you read the previous threads it may be clear why the previous PR submitter was very keen on having "precedence rules" - also people may use a blank scenario to "catch all", what happens if the same path appears in 2 files, and what is the order in which you recurse sub-directories

I'd like to stick to --mock if you don't mind unless you can figure a way to alias --mock and --mocks which may be possible with picocli

[dinesh19aug]

@ptrthomas I see your point. Since I currently have a workaround in my code. I am good with sticking to --mocks. I won't run into the issue for same path as we are using api name in the path and each Api has a different name. However, looking at the old comments I now understand what was motivation for not adding this.

[ivangsa]

following back, we find this feature very useful: spliting mocks in several feature files (and also configuring a prefx/contextPath)
obviously paths can no be repeated in different files or first one will take precedence.. and default scenario would only make sense in last feature

there is already a draft PR #1570 already for this... if you guys agree I can update it to open

[ptrthomas]

has @dinesh19aug tested this ?

[dinesh19aug]

@ptrthomas / @ivangsa - This is how I tested and it matches the the intended behavior:

Test 1: Single feature file with same paths
Given mock files test1.feature
When two scenarios with same path exist - /test exists
Then first scenario is picked up.

test1.feature
Feature: stateful mock server
----> The response file Bye.txt will be displayed
Scenario: pathMatches('/test')

• def response = read('/example/Bye.txt')

Scenario: pathMatches('/test')

• def response = read('/example/hi.txt')

Test 2: Multiple feature file with same path
Given mock files test1.feature and test2.feature start the server as java -jar karate.jar -m test1.feature -m test2.feature -W
When two scenarios with same path exist - /test exists in test1.feature and test2.feature
Then first mock file's first scenario is picked up.

test1.feature
Feature: stateful mock server
---> The response file Bye.txt will be displayed
Scenario: pathMatches('/test')

• def response = read('/example/Bye.txt')

test2.feature
Feature: stateful mock server
Scenario: pathMatches('/test')

• def response = read('/example/hi.txt')

Started the server as java -jar karate.jar -m test1.feature -m test2.feature -W

Based on this I am getting the correct behavior.

[ptrthomas]

@dinesh19aug thanks - re-opening

[ptrthomas]

merged ! thanks all. would be nice if someone contributes documentation (just a few lines should do) we don't have a date yet in mind for release

[dinesh19aug]

@ptrthomas I will add some documentation

[dinesh19aug]

Updated documentation: #1585

[ptrthomas]

1.1.0 released