We're seeing a failure with the "Browse test_combinatorial_browse_results_pagination" test:
Fail: Index + count should equal total at the end of a container. (expected 50 != actual 85)
It seem that the test is not doing the right thing. It makes two requests:
First:
<ns1:getMetadata>
<ns1:id>browse:own-playlists</ns1:id>
<ns1:index>0</ns1:index>
<ns1:count>100</ns1:count>
</ns1:getMetadata>
Second:
<ns1:getMetadata>
<ns1:id>browse:own-playlists</ns1:id>
<ns1:index>0</ns1:index>
<ns1:count>100</ns1:count>
</ns1:getMetadata>
We since these are both identical requests for the first page of results, we return the same result both times from our SMAPI service:
<index>0</index>
<count>50</count>
<total>85</total>
And the test complains that index + count != total at the end of a container. If the second request did the right thing and requested the second page:
<ns1:getMetadata>
<ns1:id>browse:own-playlists</ns1:id>
<ns1:index>50</ns1:index>
<ns1:count>100</ns1:count>
</ns1:getMetadata>
Then we would return
<index>50</index>
<count>35</count>
<total>85</total>
And, index + count = total, would be true.
The test seems to be doing the wrong thing?
This looks like it's because the test is asking for 100 items (<count>100</count>) but you're only returning 50, while telling the test that there are a total of 85. Try returning all 85 at a time.
Related
I try to compare the response time with certain amount of time, but I don't know how to do it. I dont even know if the number I give is taken as seconds or milliseconds
This is my code:
Scenario: Case
Given url 'https://reqres.in/api/users?page=2'
When method GET
Then print responseTime
* def time = response.data.responseTime
And assert response.data.responseTime < 10
The response:
I've also tried putting the numbers like milliseconds, but get the same result :(
This worked for me, try it. It is milliseconds:
* url 'https://httpbin.org/get'
* method get
* assert responseTime < 2000
Refer docs: https://github.com/karatelabs/karate#responsetime
That said, I personally don't recommend this kind of assertions in your tests. That's what performance testing is for: https://github.com/karatelabs/karate/tree/master/karate-gatling
Returns a list of tests for a test run
https://www.gurock.com/testrail/docs/api/reference/tests#gettests
There is an API from Test Rail, it will return a list test case from one test run (id)
This is a limitation, only return up to 250 entities in once.
How can I get more than 400 or 500 case from a run?
Maximum and default value of limit parameter is 250, you can't get more than 250 with one request. But they have offset parameter for that, so you can set the start position of the next chunk.
And also you can use "next link" from the response, here is the example:
"_links": { "next": "/api/v2/get_tests/1&limit=250&offset=250", "prev": null }
Here is some python code I wrote that will query to get all of the results.
def _execute_get_until_finished(self, resp, extract):
results = []
finished = False
while not finished:
results.extend(resp[extract])
finished = resp["_links"]["next"] is None
if not finished:
resp = self.send_get(resp["_links"]["next"].replace("/api/v2/", "").replace("&limit=250", ""))
return results
Example:
cases = self._execute_get_until_finished(
self.send_get(f"get_cases/{self.project_id}/{self.suite_id}"),
"cases")
Note, reason for removing limit is a bug I found where next would be null even though there were still results to retrieve. Removing this limit fixed that issue.
I want to post some bulk messages. System takes some time to process them, so i do not want to proceed for 2nd iteration. My setup is something like this
While controller->jdbc request->beanshell postprocessor
In While controller, condition is ${__java script("${check_1}" != "0")}
check is the variable name as part of database sampler which checks whether all the messages are processed. Its a count, if it is 0 we have to stop looping.
As part of Bean Shell Post Processor, i have added a condition to wait if count is not equal to 0.
if(${check_1} != 0) {
out("check Count not zero, waiting for 5 sec " + ${check_1});
Thread.sleep(5000);
}else
out("check Count is zero " + ${check_1});
Whats happening is, the result is something like this
If the check_1 is > 0 , it waits for 5 sec and as soon as it is 0, it runs into infinite loop by executing the sampler multiple times
Is there something wrong with the condition. Please suggest if you have any other solution.
The correct way to use __javaScript() function and define condition is:
${__javaScript(${check_1} != 0,)}
The correct way of accessing JMeter Variables from Beanshell is:
if(vars.get("check_1").equals("0"))
Hope this helps.
We run multiple short queries in parallel, and hit the 10 sec limit.
According to the docs, throttling might occur if we hit a limit of 10 API requests per user per project.
We send a "start query job", and then we call the "getGueryResutls()" with timeoutMs of 60,000, however, we get a response after ~ 1 sec, we look for JOB Complete in the JSON response, and since it is not there, we need to send the GetQueryResults() again many times and hit the threshold, that is causing an error, not a slowdown. the sample code is below.
our questions are as such:
1. What is a "user" is it an appengine user, is it a user-id that we can put in the connection string or in the query itslef?
2. Is it really per API project of BigQuery?
3. What is the behavior?we got an error: "Exceeded rate limits: too many user/method api request limit for this user_method", and not a throttling behavior as the doc say and all of our process fails.
4. As seen below in the code, why we get the response after 1 sec & not according to our timeout? are we doing something wrong?
Thanks a lot
Here is the a sample code:
while (res is None or 'jobComplete' not in res or not res['jobComplete']) :
try:
res = self.service.jobs().getQueryResults(projectId=self.project_id,
jobId=jobId, timeoutMs=60000, maxResults=maxResults).execute()
except HTTPException:
if independent:
raise
Are you saying that even though you specify timeoutMs=60000, it is returning within 1 second but the job is not yet complete? If so, this is a bug.
The quota limits for getQueryResults are actually currently much higher than 10 requests per second. The reason the docs say only 10 is because we want to have the ability to throttle it down to that amount if someone is hitting us too hard. If you're currently seeing an error on this API, it is likely that you're calling it at a very high rate.
I'll try to reproduce the problem where we don't wait for the timeout ... if that is really what is happening it may be the root of your problems.
def query_results_long(self, jobId, maxResults, res=None):
start_time = query_time = None
while res is None or 'jobComplete' not in res or not res['jobComplete']:
if start_time:
logging.info('requested for query results ended after %s', query_time)
time.sleep(2)
start_time = datetime.now()
res = self.service.jobs().getQueryResults(projectId=self.project_id,
jobId=jobId, timeoutMs=60000, maxResults=maxResults).execute()
query_time = datetime.now() - start_time
return res
then in appengine log I had this:
requested for query results ended after 0:00:04.959110
I am trying to search a LDAP server(Active Directory). When I parse the search results, the hasMoreElements method of NamingEnumeration takes around 15-20 seconds to execute when it returns false. It is not the case when it is returning true. Is there a way to solve this issue?
Code:
SearchControls ctrl = new SearchControls();
ctrl.setSearchScope(SearchControls.SUBTREE_SCOPE);
String searchFilter = "(&(objectClass=user("uid"="abc"))";
NamingEnumeration ne = dirContext.search("ldap://abc:389/dc=abc,dc=xy", searchFilter,ctrl);
if (ne != null) {
while (ne.hasMoreElements()) {
//parse results
}
The NamingEnumeration does some cleanup when calling hasMoreElements() the last time. It also checks if there are additional referrals is the context-property Context.REFERRAL is set to "follow". In one case in our software this caused exactly the behaviour as described: The last call to hasMoreElements() (or to hasMore() or calling next() more often than allowed) caused up to 40 seconds as referrals are searched in the LDAP context. The solution is to not set Context.REFERRAL to "follow".
AD has a default limit of number of objects it returns in an LDAP query. I think it is in the 1000 object range.
If you hit 1001, you get 1000 returned, then an error, so I could see this being the case.
Count how many objects you get back in a test, and betcha you beat 1000 and then fail.