VSCodeHook to communicate with vscode, sending start-end events and http logs.

[ivangsa]

RuntimeHook to comunicate with vscode, sending start-end events and http logs in real time.

• Relevant Issues : Split logback logs into multiple subloggers | Implement a LogsServer #1389
• Relevant PRs : (optional)
• Type of change :
  • New feature
  • Bug fix for existing feature
  • Code quality improvement
  • Addition or Improvement of tests
  • Addition or Improvement of documentation

[ptrthomas]

@ivangsa seems to be a custom requirement, does not need to be in core IMO

[ivangsa]

@ptrthomas yes is a custom requirement but it would help adoption if provided by karate and users don't need to add it
it will not affect other users as is a separte hook
would you consider adding this?

[ptrthomas]

@ivangsa I don't think this will make it into 1.0 for sure. it also is an area that needs time to think through and validate if this needs to be more generic, and to be honest I still haven't understood exactly what this is trying to solve.

I would also like feedback from @kirksl

[ivangsa]

@ptrthomas ok, I undestand if this needs time to think through and validate
it is going to be a different extension from original karate-runner from @kirksl, they are two very different code styles that don't mix well
I will proceed with the vscode extension, I hope you will consider this for a future karate version

[kirksl]

while we're at it can we proceed with releasing a 2nd version of Peter's Karate project too? 🙂

i think ivan has some great suggestions and additions here, but agree we need to properly vet everything.

@ivangsa happy to work with you and be "very" accommodating with your asks in an effort to fuse our solutions together into the existing Karate Runner extension. also in agreement that there are quite a number of differences between our implementations, but that shouldn't serve as reason to publish an entirely new extension nor go against working together.

consider the implications. each of us will probably hate each other over time, double the work, wasted time competing, the extensions will be diluted/weakened as a whole with 2 releases, users will likely be confused and/or unhappy generaly, especially if each version of the extension offers something the other doesn't that they really want. which one will the choose?

please reconsider as i'm ecstatic to join forces.

[ivangsa]

hi @kirksl, it's nice to talk you again

first I agree that ideas may need to thought throught, and properly vet everything..

and I think I understant the implications of having two different extensions in terms of

• fragmentation vs diversity
• double work vs coordination
• handling all issues vs shared support
• users confusion

I took all this into consideration back in december... when approached you..
I know that saying, that "going along can move faster but going together can get farther"...

But I first expressed my concerns here (remember?):
kirksl/karate-runner#74 (comment)

• code style was very different and hard to merge and keep compatible overtime
• but more important your project has been very irresponsive... we got two PRs waiting for 20 days without any comment or answer (and yes one was very experimental, but the other one as small usefull and self-contained)

After our conversation we almost agree in:

• we are going to develop some functionality we needed and in a couple of weeks we will back to you to see to merge them to your project
• we were going to re-format code using prettier, which is somehow an standard for js/ts code formatting, to avoid incompatibilities in code

Remember? ZenWave360/karate-ide#1 (comment)

Well, what happend after two weeks when we got back to you was:

• you refactored our contributions to your project to a different style and we have refactored all your project using prettier (as 'agreed' before) => this means code don't merge anymore
• but also and more important we asked your for a code review, if we are going to merge this... "I think if we can agree on this refactoring all the rest would be just simple evolution..."
  Track first iteration fork efforts ZenWave360/karate-ide#1 (comment)

and we didn't really get any code review (and it was later I found out about the code refactoring that made merging hard if not imposible...)

I don't expected this to work... I don't think I'm going to hate you or your extension at all.. I already show you our appreciation for your work, without it we wouldn't even start this..

The main reason we did this fork is because we need this functionality for every day work... I'm work for a team of ~10 people dedicated to write api testing as main task, and for apis they are not developers nor users (so they don't really know tha api and need tools to explore)...
We created the extension we need for ourselves, some may like it and some may not, but we do... And I need to publish it to the marketplace because I can not keep sending zip files all the time..

I'm not sure, but I would keep the original karate-runner for compatibility with previous karate version

And if you want to keep developing the extension you can join forces in our project, you will be more than welcome...
I'm not sure about how this would work, but I still mean it... (any way prettier formating will be required)

And I would say this once again, I thank you for all the effort you put into this because is an important part of our daily work. So thanks for that!

Now please take your time, because there is no rush...

What I have in mind for the future is:

• explore generating tests and mocks from openapi definitions (some may like it, some may not, but we do have use for them)
• explore (as tentative) this "Record and Replay UI tests" https://github.com/intuit/karate/projects/3#card-36516057
• but it will be also be great to have this "Language server protocol" https://github.com/intuit/karate/projects/3#card-22529505 (low priority for me but nice to have)

I leave it like this, and sorry for this excedingly long post...

[ptrthomas]

I've just introduced methods to intercept (and even modify if needed) the http request and response as part of the runtime-hook (which has been simplified so that you only need to over-ride the methods you need to)

3899077

have not tested this - but hopefully is a generic way for users to introduce custom http logging, capture etc. for e.g. one of the possibilities would be to document all HTTP calls made by a test-suite