aksharagpostman / testing-sentiment2

0 stars 0 forks source link

m #98

Open aksharagpostman opened 5 years ago

aksharagpostman commented 5 years ago

good

aksharagpostman commented 5 years ago

good

aksharagpostman commented 5 years ago

the only way Gatling and Postman can share the same DSL is if Postman were completely re-written from scratch using Scala, and it compiled and ran Scala code for its scripting language. That's asking an awful lot. Sure, it would be cool if you could use the same code for both, but even as a Gatling enthusiast, I think it's asking too much. The problem domains are too different.

More achievable is to learn from how Gatling implemented its DSL, and create something similar. Or better yet, look at all the available web request DSL's out there, and synthesize something even better.

As I'm saying that, here's what is going through my mind:

Create a \"class\" that represents a single request. What we call a \"request\" now translates directly into code that instantiates and appropriately initializes an instance of that class. Within code, you can use that same class to manually create requests. Now, you have a path to go from GUI to code.

Where things get tricky is creating serial request execution. Users are going to expect that when they say \"Execute this request\" that the code that follows will only be executed once the request is complete. And that is a reasonable expectation, one that should be possible to meet. JavaScript makes that difficult. I'm not even aware of a way of doing so in a generic way. The JavaScript model is to do things using Promises or Callbacks, which is powerful but very hard for a novice to wrap their heads around. I do NOT recommend that Postman build its DSL around the same model.

Gatling works around this by having the DSL construct a data structure which gets executed, step-by-step. Unfortunately, this creates a situation that often trips up new users. They don't understand the difference between build-time and run-time execution. I would avoid duplicating that pattern, if at all possible.

The only thing that is left is some way of making JavaScript wait for an asynchronous process to finish before returning from a function. And that won't work, because then the GUI would stop responding while you wait for the code to finish executing.

The only other option that I can think of is for the Scripting Language to be something other than JavaScript. I imagine that option is dismissed without any serious contemplation, because it is way too big of a change.

What is left is standing between a rock and a hard place. The laudable goal of building a simple, easy, novice-friendly solution for building a series of requests in code becomes next to impossible without some serious re-thinking.

As much as I want to see it done, I don't have a ready solution for how to do it. If something comes to mind, I'll let you know.