Gatling Storing variables between scenarios - scala

I am using Gatling and am running into an issue implementing an integration test. The test I am running has two parts (scenarios):
The first part is a simple GET request to verify expected server responses. In this step, it returns a form's configuration ID as well as other properties of the form.
In the next step, I am hitting PUT route which updates various properties of this form's configuration for testing of this route and other functionality through the back ends of an application.
The issue with these steps is that after running the second step, if there are any forms saved under that configuration, it will clone a copy for security purposes and changes the ID. Long story short, the same ID does not persist from test to test.
My question is: Is there a way within Gatling to run SQL Queries to get values and store them and then pass them? OR is there a way to store a variable from the GET method and pass it in in the second scenario's PUT method. I know there is Gatling's .saveAs() method, but I believe the scope of this function is only scenario.
Please notify me for further clarification and details; thanks in advance.

The Google group link only shows you how to share (&cache) data between different user-sessions.
If you are looking for sharing data between "scenarios" rather than "user sessions", you should check out Peter's answer: https://stackoverflow.com/a/43061278/1395126
It's the only information I can find on the internet today that really shows you how to share data between scenarios in Gatling.
IMHO, it's super important to look out for the line of "// Set it here" comment. This is THE secret about sharing data among scenarios. Without setting session attribute first or accessing the "CreateId" directly in another scenario could not work.

This answer: https://groups.google.com/forum/#!topic/gatling/bfpKd_9d6gk can probably be used to handle your use case.

Related

How exactly does backend work from a developer perspective?

Theres a ton of videos and websites trying to explain backend vs frontend, but unfortunately none of them explains it in a way that you know how to develop a backend - driven website (at least I haven't found anything good).
So, I wanted to ensure that I understood it and kindly ask you to confirm or correct me on this topic.
Example:
I wanted to build Mini - Google. I have a Database containing 1000 stored websites.
Assumption #1:
Everytime I type something into the search bar, the autofill suggestions change. This means, everytime i type, another website / API gets called returning the current autofill suggestions. On a developer site, this means the website e.g. is a Python script which gets called with the current word typed in as a Parameter and is returning all suggestions as e.g. JSON:
// Client Side Script
function ontype(input):
suggestions = get("https://api.googlemini.com/suggestions?q=" + str(input))
show(suggestions)
Assumption #2:
This also means I could manually call the website containing the Python script, providing a random word and it would always return a JSON containing the autofill suggestions for that word.
Question #1:
If A#1 turns out true but A#2 turns out false, how could I prevent a user from randomly accessing the "API" while still returning results when called by a script?
Assumption #3:
After pressing enter, my website googlemini.com/search?... would be called. As google.com/search reloads everytime searching for a new query (or going to page 2 etc.), I assume, instead of calling an API, when the server gets the client request, it first searches through its database, sorts the results and then returns a whole html as a static webpage:
// Server Side Script
#app.route("/search")
function oncall():
query = getparam("q")
results = searchdatabase(query)
html = buildhtml(results)
return html
Question #2:
Often, I hear (or at least understand it this way) that database and webserver are 2 seperate servers. How would that work? Wouldn't that mean the database server needs to be accessible to the web too (of course it would have security layers etc., but technically it would)? How could I access the database server from the webserver?
Question #3:
Are there, on a technical basis, any other ways to build backend services?
That's it. I would also appreciate any recommendations like videos, websites or others to learn how to technically setup and / or secure backend servers.
Thanks in advance.
For your first question you can yes there is a way to prevent miss use.
What you can do is add identifier to api like Auth token to identify a user and every time a user access the api you can save the count on the server n whenever the count has exceeded a limit within a time span you can reject the call. And the limit can be set in such a way that it doesn't trouble the honest user and punishes the wrong one. There are even more complex and effective methods but this is the basic idea.
For question number to let me explain you a simple concept a database is a very efficient, resourcefull and expensive data storage solution we never want it to be used in a general sense as varible store or something. We always want to access the database in call get the data process the data update the data. So we do it data way and its not necessary you make sepreate server for data base. The thing is we mostly make databse to be accessible to various platforms android, ios, windows. So its better to add some abstraction and keep data base as a separte entity.
For the last, I am not well aware about what you meant by other but I am listing some backend teechnologies, some of these might be used in isolation some of these not some other tools as well.
Django
FLask
Djnago rest
GraphQL
SQL
PHP
Node
Deno

Restful business logic on property update

I'm building a REST API and I'm trying to keep it as RESTful as possible, but some things are still not quite clear for me. I saw a lot of topic about similar question but all too centered about the "simple" problem of updating data, my issue is more about the business logic around that.
My main issue is with business logic triggered by partial update of a model. I see a lot of different opinion online about PATCH methods, creating new sub-ressources or adding action, but it often seems counter productive with the REST approach of keeping URI simple and structured.
I have some record that need to be proceeded ( refused, validated, partially validated ..etc ), each change trigger additional actions.
If it's refused, an email with the reason should be sent
if it's partially validated, the link to fulfill the missing data is sent
if it's validated some other ressources must be created.
There is a few other change that can be made to the status but this is enough for the example.
What would be a RESTful way to do that ?
My first idea would be to create actions :
POST /record/:id/refuse
POST /record/:id/validate ..etc
It seems RESTful to me but too complicated, and moreover, this approach means having multiple route performing essentially the same thing : Update one field in the record object
I also see the possibility of a PATCH method like :
PATCH /record/:id in which I check if the field to update is status, and the new value to know which action to perform.
But I feel it can start to be too complex when I will have the need to perform similar action for other property of the record.
My last option, and I think maybe the best but I'm not sure if it's RESTful, would be to use a sub-ressource status and to use PUT to update it :
PUT /record/:id/status, with a switch on the new value.
No matter what the previous value was, switching to accepted will always trigger the creation, switching to refused will always trigger the email ...etc
Are those way of achieving that RESTful and which one make more sense ? Is there other alternative I didn't think about ?
Thanks
What would be a RESTful way to do that ?
In HTTP, your "uniform interface" is that of a document store. Your Rest API is a facade, that takes messages with remote authoring semantics (PUT/POST/PATCH), and your implementation produces useful work as a side effect of its handling of those messages.
See Jim Webber 2011.
I have some record that need to be proceeded ( refused, validated, partially validated ..etc ), each change trigger additional actions.
So think about how we might do this on the web. We GET some resource, and what is returned is an html representation of the information of the record and a bunch of forms that describe actions we can do. So there's a refused form, and a validated form, and so on. The user chooses the correct form to use in the browser, fills in any supplementary information, and submits the form. The browser, using the HTML form processing rules, converts the form information into an HTTP request.
For unsafe operations, the form is configured to use POST, and the browsers therefore know that the form data should be part of the message-body of the request.
The target-uri of the request is just whatever was used as the form action -- which is to say, the representation of the form includes in it the information that describes where the form should be submitted.
As far as the browser and the user are concerned, the target-uri can be anything. So you could have separate resources to handle validate messages and refused messages and so on.
Caching is an important idea, both in REST and in HTTP; HTTP has specific rules baked into it for cache invalidation. Therefore, it is often the case that you will want to use a target-uri that identifies the document you want the client to reload if the command is successful.
So it might go something like this: we GET /record/123, and that gives us a bunch of information, and also some forms describing how we can change the record. So fill one out, submit it successfully, and now we expect the forms to be gone - or a new set of forms to be available. Therefore, it's the record document itself that we would expect to be reloading, and the target-uri of the forms should be /record/123.
(So the API implementation would be responsible for looking at the HTTP request, and figuring out the meaning of the message. They might all go to a single /record/:id POST handler, and that code looks through the message-body to figure out which internal function should do the work).
PUT/PATCH are the same sort of idea, except that instead of submitting forms, we send edited representations of the resource itself. We GET /record/123, change the status (for example, to Rejected), and then send a copy of our new representation of the record to the server for processing. It would therefore be the responsibility of the server to examine the differences between its representation of the resource and the new provided copy, and calculate from them any necessary side effects.
My last option, and I think maybe the best but I'm not sure if it's RESTful, would be to use a sub-resource status and to use PUT to update it
It's fine -- think of any web page you have ever seen where the source has a link to an image, or a link to java script. The result is two resources instead of one, with separate cache entries for each -- which is great, when you want fine grained control over the caching of the resources.
But there's a trade - you also need to fetch more resources. (Server-push mitigates some of this problem).
Making things easier on the server may make things harder on the client - you're really trying to find the design with the best balance.

Attempting to Create a User Login for Clojure / Korma / PostgreSQL site

I am completely stuck on where to start with getting a log-in area for a Clojure site I am building (for fun).
I've looked at several resources, which I'll post below, mercilessly copy/pasted code, and the closest I can get is one of two situations:
The login page takes the login but says that the login failed, though, as far as I can tell, the login matches.
Or I get this error: No method in multimethod '->sql' for dispatch value: null
I'm not sure how to interpret the above error: is this specifying that I need a multi-method or is it specifying that I need to check for null? The null requirement makes no sense at all. I'm not really asking but if anyone wants to give an explanation, that is great.
I tested the output by comparing the results-to-select queries from raw non-hashed data, I've went through 5 variations on this theme, using everything from page-to-page calls to creating new defpartials, multi-methods, defn, etc.
Sources I have used (unfortunately, I can't list all of them being a first-time poster):
This one uses Clojure -> Korma -> PostgreSQL, but the code doesn't seem to work for multiple users?
http://www.vijaykiran.com/2012/01/17/web-application-development-with-clojure-part-2/
This one shows how to use Noir and PostgreSQL (Yes, I am using Noir):
https://yogthos.net:11794/blog/23-Noir+tutorial+-+part+2
The 4Clojure site, but that one uses CongoMongo:
The Heroku Twitter clone, but no mention of how to create logins for one person, much less several.
I also bought Programming Clojure from O'Reilly Press, but once again, nothing about how to create a log-in area.
FIRST EDIT: I was asked to create a github repository of a stand-alone site. This includes a working "Account Creation" area that is found in the welcome.clj file and only a form of the Login area in login.clj.
I was attempting to get some of the same errors working as I had last night and also attempting to get this working before I uploaded the files. I don't have any reasonable starting points yet, thus there is no beginning implementation as of yet. I'm seriously embarrassed at the solutions I've been coming up with, thus I don't want to post them. I get conceptually what I should do, but for some reason, I can't seem to translate this. This is my first github account: my background is Python, Scheme a'la SICP, and some Python + PostgreSQL marketing program I built.
SECOND EDIT: Ack! I can't seem to get the thing to work at all... Yeah, I spent well over 20 minutes (hours) on this one, so I have just have to admit that I don't yet have the requisite knowledge to accomplish this, no matter how many sources I look to. I committed the updated files and all the odd things I tried, including all the variations on login box to running raw SQL. The closest I can come is getting it so that I don't get any errors, but no evidence at all that someone is logged in. Thanks so much for the help and suggestions. I'll most certainly return to this later.
https://github.com/dt1/noirKormaLogin
There are a couple of issues that I see. First, in datapass.clj, you're creating an entity with no content. I'm not sure how Korma handles that. It's trying to thread results as inputs to other functions, so I could see how nil gets introduced there.
Secondly, you'll need something to handle the login post. (defpage ...) only handles GET requests by default. You'll need a separate defpage to handle the post. Something along these lines:
(defpage [:post "/login"] {:keys [user-name pwd]}
(if-let [user (db/find-user user)]
(if (noir.util.crypt/compare pwd (:password user))
(do
(noir.session/put! :some-key some-value)
(noir.response/redirect "/success"))
noir.response/redirect "/failed-to-login"))
(noir.response/redirect "/failed-to-login"))
session/put! is how you put data into the session. The default is to use an in-memory store. You'll need to add Ring middleware to use persistent sessions (look at Session Stores).
Also, as luck would have, someone just posted an authentication app for Noir... you may want to take a look: https://github.com/xavi/noir-auth-app

CQRS: how do you retrieve information about an executed command?

In most command interfaces I've seen, there is typically an "Execute" method which takes takes a command input and either returns void or some generic structure indicating if the command executed successfully or not (we are using the latter). Now, I've never thought of this before, but we suddenly got the need to know some more details about the result of the command than what you can expose generically.
Consider the following example:
you have a team and you are creating a screen where you can add members to your team. The members of the team are shown in a grid below the "add new member"-stuff. Now, when you press "add new member" you want to run some jquery/roundohuse/whatever and add the new member to the list of team members. No problems so far, but: you also want to include some identification data in a hidden field for each member and this id-data comes from the server.
So the problem is: how can I get that id-data from the server? The "AddNewTeamMember" command which I am pushing through the "ExecuteCommand"-method does not give me anything useful back, and if I add a new query method to the service saying something like: "GetLastAddedTeamMember" then I might just get the last entry added by someone else (at least if this is data which is very aggressively added by different users). In some situations you have a natural unique identifier generated on the client side which we can use, but for team members we did not.
Given that you have no choice but to update an on-page widget when another command completes, I see two choices for you:
Shoot off the command, display something locally that indicates it is submitted, and then wait until you get a notification from the server that the team member list has changed. Update the widget to reflect that.
Add a correlation ID to your command when you submit it, and add the team member provisionally locally to the list. When you get a confirmation from the server that a team member update happened because of your correlation ID, update your local data.
I would suggest the first approach, where the "provisional indicator" could be throwing a marked version of the normal indication into place; then, when you finally get an update you should have the data you need.
Given you went with CQRS to solve this problem I assume you have frequent updates to the content of those widgets happening in the background already, so have presumably solved the "background update" problem.
If not, I suggest you either ditch CQRS as a bad - over-complicated - solution in your problem space, or solve the background update problem first.
If you want to add an existing team member, you should query the read side of your application for this data. If you need to add a new team member, you have to consider if it's necessary to show the user in the grid below at once. Can you wait until the team member is in place on the read side? You can also query a service on the server side to get an unique ID (it can return a GUID). Then you add the team member to the grid, and of course, send the command to the server. But, if it's possible, try to design the application in a way that you don't have to show the team member at once. It's also possible to give the user a message saying something like this: "Team member added, waiting for response from server.". Then use AJAX to query the read side for new team members. When it appears on the read side, show it in the grid. You might have to deal with team members added by other users, but does it matter? CQRS gives you a great way to collaborate with other users, so maybe you should take advantage of that. As I see it; CQRS forces you to think different, and that may not be a bad thing.

What is the perlish way to test a web application, especially with regards to concurrent access?

I am working on a web application that uses CGI.pm to realize the user interaction. Now I like to test my changes by implementing unit tests. These are my requirements:
Perlish way
Low effort to implement the Unit test validating a simple workflow.
My web application consists mainly of two forms displaying and changing
the content of a flat file database.
Allow testing the concurrent access of multiple user.
This should ensure that e.g. the locking is performed the right way.
I am not interested in performance measurement.
Integration with Ecplise (EPIC)
Readable and Speaking unit tests
So far I have found these packages: CGI::Test, Test::HTTP, HTTP::WebTest and Test::WWW::Mechanize.
CGI::Test as a project seams rather dead, last change in Oct. 2003.
Test::HTTP focuses on the HTTP connection.
HTTP::WebTest is running tests from test specifications. Many more packages, but last change in Sep. 2003.
Test::WWW::Mechanize comprehensive and modern interface. Maintained for some time by multiple persons. Readable tests, but seams to focus on testing static pages (perhaps this is not correct, but only based on quantity of methods). Filling a form is possible using submit_form_ok, but there is no example showing that it is possible to check the returned page. Testing concurrent access is not obvious for me, too.
So my research would lead to Test::WWW::Mechanize. Will this be a correct way?
Thanks in advance for your help.
Test::WWW::Mechanize is a good way to go.
Test::WWW::Mechanize is a subclass of WWW::Mechanize and Test::WWW::Mechanize->new returns an object that is a subclass of LWP::UserAgent. So it would help you a lot if you read and understand the documentation for those libraries. For example, the WWW::Mechanize documentation will explain to you how to submit a form and retrieve its content.
Example
Here is an example that tests simultaneous access by 2 users and shows how to check the results (adapted from the Catalyst testing tutorial):
my $ua1 = Test::WWW::Mechanize->new; # user agent 1, Bud
my $ua2 = Test::WWW::Mechanize->new; # user agent 2, Ace
# Log in as each user
$ua1->get_ok("http://localhost/login?username=Bud&password=xxx", "Login 'Bud'");
$ua2->get_ok("http://localhost/login?username=Ace&password=xxx", "Login 'Ace'");
# Go back to the login page and it should show that we are already logged in
$_->get_ok("http://localhost/login", "Return to '/login'") for $ua1, $ua2;
$_->title_is("Login", "Check for login page") for $ua1, $ua2;
$_->content_contains("Please Note: You are already logged in as ",
"Check we ARE logged in" ) for $ua1, $ua2;
Brief explanation:
get_ok($url, $msg):
Checks to make sure $url can be retrieved. $msg is displayed when the test fails.
title_is($title, $msg):
Checks the contents of the <title>...</title> tags. $msg is displayed when the test fails.
content_contains($content, $msg):
Checks if the regular expression $content matches anything in the html body. $msg is displayed when the test fails.
More things to think about
You might want to look at Test::WWW::Mechanize::CGI. It allows you to test without running a webserver.
The WWW::Mechanize::FAQ could be useful to you if you are looking for examples.
I propose to split testing into two parts:
Testing interface with Test::WWW::Mechanize. Test::WWW::Mechanize is good for both static and dynamic pages, but it's purpose is dynamic pages. After submit_form_ok you need to use methods like content_contains, content_like and other methods of "CONTENT CHECKING" group. Also, Test::WWW::Mechanize is a WWW::Mechanize subclass, so you can use any WWW::Mechanize methods like "content".
Testing parallel access. Split that part of your program into separate library and test it using Test::More and fork.