Is there a way to make a global change to the default timeout for the element level waits in the page-object gem? We use the default 5 seconds but need to change it once in a while depending on the environment. Our main test environment runs on several servers so responds times are very fast. However we have one or two environments that run on one server only and respond times are a little slow. I would like to change this value based on the environment. I realize this is not ideal but it is something I was asked to look into.
Thanks.
https://github.com/cheezy/page-object/issues/79
Two things to set. PageObject.default_page_wait will set the default timeout value for page level actions and PageObject.default_element_wait will set the default timeout value for element level actions.
Related
I have a sinatra (ruby) based web application which is used to control the workflow for end users.
It appears there is one task that can take so long that the session is nil at the time it is ready to perform the next step. It results in an error message and the task is not completed properly.
I want to increase the session timeout (if it is possible at all). But first, since I have not explicitly set it, I want to know the actual value of the timeout interval. Is there a way to access and print that?
In JMeter when I right click Thread/Controller I have an option: Add Think Time to children feature , when I click on it I get after every Sampler Test Action Pause with Uniform Random Timer with Random Delay 100 and Constant Delay 1000.
I didn't find in documentation any reference to it and why/how it should be used.
Is it configurable and how? is there a special case for it or should it be used for loading best practice ?
Also you can add several times think times I'm not sure is it on purpose (add more delays after request)
EDIT
Configurable using jmeter.properties:
# Default implementation that create the Timer structure to add to Test Plan
# Implementation of interface org.apache.jmeter.gui.action.thinktime.ThinkTimeCreator
#think_time_creator.impl=org.apache.jmeter.thinktime.DefaultThinkTimeCreator
# Default Timer GUI class added to Test Plan by DefaultThinkTimeCreator
#think_time_creator.default_timer_implementation=org.apache.jmeter.timers.gui.UniformRandomTimerGui
# Default constant pause of Timer
#think_time_creator.default_constant_pause=1000
# Default range pause of Timer
#think_time_creator.default_range=100
When it comes to web applications load testing the idea is to represent a real user sitting in front of computer using a real browser as close as possible.
Well-behaved JMeter test needs to mimic this real user with all its stuff like:
headers
cookies
cache
embedded resources
AJAX requests
etc.
The purpose of using Timers in JMeter tests is simulating real users "think times". Users don't hammer application non-stop, they need some time to "think" between operations, fill forms, type comments, even clicking on a button or link takes some time. So if you are testing if your web application supports X users each JMeter thread must act like a real user so you need to add reasonable think times using Timers. There is no "best practice" or "known good values", it depends only on your web application specifics. See A Comprehensive Guide to Using JMeter Timers for more details.
This feature is made to simplify addition of Think Times, the way it adds them to plan lead to pause between every sampler while if you just add a Timer it will be scoped and thus be applied before all samplers in scope.
As it's a helper, it adds default Pause of 1 second that are configurable by tuning the properties you have mentioned and which are documented :-) :
http://jmeter.apache.org/usermanual/properties_reference.html#timer
You can adjust:
The type of Timers you want to create
The constant and variable pause range
You can even create your own class that would work differently.
This may be theoretical more than anything else; a solution would be remarkable, but any feedback/ideas are just as welcomed.
In simple terms, I'm wondering if it's possible to to update an environment variable in an active session on rstudio-server, from a background process outside of the session altogether.
For example, let's say:
We have a script that is run every minute as a cron job which polls a series of websites and parses certain elements into a data.frame
Our function first reads in the data.frame that was initially created, and if it detects changes in the websites we're polling, it appends a new row with a time-stamp, and then saves the data.frame back to the rds file; if it does not find any differences it simply exits.
In our .First function, every session begins with assign('.url_df', readRDS('/home/user/url_checkr.rds'), envir = .GlobalEnv) so that we always have the latest update assigned into the active working session, and it always has the same variable name globally.
The goal is now to be able to update that environment variable from our external script, running on cron or alternative, with any updated rows if necessary.
I know how it's possible to send messages between terminals using echo msg > /proc/$pid/fd/0 and know we can use system('ps', intern=TRUE) in our INITIAL function to check for any active sessions and get their pid. The question is how would we/is it possible to use this approach to actually update that .Global variable in the background of the active session with any updated fields? From there it wouldn't be hard to formulate ways to send messages to the console etc.
Purely curious / unsure if im wrapping my head around the whole idea properly?
Thanks!
I think the most straightforward way to do this would be to use R's addTaskCallback function.
This function effectively allows you to run code every time a top-level R task completes (i.e. after every R expression that's executed in the console). You could establish a task callback which effectively does what you're doing in .First (i.e. updates the global variable if necessary). With the callback in place the global variable would update automatically in the background as users continue to execute R code.
Depending on the size of your data, you might want to add some safeguards so that the entire RDS file isn't read from disk every time; for instance, you could write a checksum along with the file and just check to see if the checksum is different.
If I cannot, is there a scope that will make the same cfldap query available to all users? I'm just trying to cut down on the number of times it is called, since it's a cross-server call.
Step 1 - write some code that gets your ldap data and persists it somewhere. This could be a database, text file, or perhaps even a ColdFusion variable in the server scope.
Step 2 - Schedule that code to run at whatever frequency is good enough for your requirements.
The reason I mentioned server scope instead of application is that I'm not sure how hard it is to write application variables using scheduled jobs. I've never had a reason to try.
What is purpose to use setup threadgroup and teardown threagroup in Jmeter? Please explain same with example.
I know why we use thread groups and also aware of fact that setup is for pre activities like creating user and monitoring purpose but not sure with an incident where can i use it. same with tear down.
It sounds like you have pretty much figured it out already, but let me give you a few examples of when I've used it.
setup:
Get a large data set from a database into a jmeter variable for use during the test.
Get and log the version number from the system under test:s version number.
Run a javascript to set jmeter properties based on more simple input parameters/properties. Lets say you want to configure the selection of target host a simple true/false value, but in your test you need to expand it to different strings, and you dont want to have logic spread out all over your test plan.
teardown:
Never used it, but I guess it is mainly useful for cleaning up your system (e.g. deleting users that were created during the test)
correct me as i'm probably wrong, but a setUp thread cannot be used to store variables for use on the test threads (that i can see). any variables that i use in the setUp are never available. however, i found that if i use a beanshell and convert the variable in the setUp thread to a property like this
${__setProperty(userToken, ${userToken})};
then on each test thread i either use the property directly like:
${__property(userToken)}
or at the top of my thread i convert the property back into a variable like:
vars.put("userToken","${__property(userToken)}")
however, this seems a bit long winded and it would be great if there was a way to set up variables in the setUP to be used on every thread.
A special type of ThreadGroup that can be utilized to perform Pre-Test/ Post-Test Actions.The behavior of these threads is exactly like a normal Thread Group element.
The difference is that these type of threads execute before/after the test has finished executing its regular Thread Groups.enter image description here