I recently started using the Katalon Studio, for automation. While writing the scripts I checked if an object is present or not on the DOM by using:
if(findTestObject('{Object ID}')){
//do some work
} else{
//do another work
}
if the object is found it's all good, but if it isn't, it continues executing in the else block, but in failure log it shows it as a failure. I've tried implementing some of the solutions to fix it that were on the Katalon discussion page, but none of them worked.
Is there any way to stop counting the else block code into failure?
Recommended way is using Verify Element Present. Try changing your script to:
if(WebUI.verifyElementPresent(findTestObject('{Object ID}'), 5)){
//do some work
} else{
//do another work
}
(in this example, '5' is the timeout you expect to find the element in, lower it if needed).
I believe this happens because findTestObject only returns reference to object in Object Repository but does not guarantee the element is really loaded in DOM.
Related
I'm working on some automated tests, using webdriverIO, Mocha and Chai. I keep running into the same problem when I want to verify if an element is deleted.
I'm working with a shoppingbasket where i delete an item and then verify that it is gone. It takes a while for the item to be gone though, so if I immediately go to the expect, the item is still there.
I have solved this by doing this:
browser.waitForExist(deletedProduct, 5000, true)
expect (boodschappenLijstPage.isProductPresent(SKU), 'the removed item was still there' ).to.equal(false)
The webdriverIO waitfor command waits for the product to dissapear, and after that the chai expect checks if it is gone.
The problem I have with this is that the expect will never fail. If the product is not properly deleted the waitfortimeout will throw an error before I get to the expect part, meaning that the expect part is only reached if the product is gone
I have read through the docs for chai, but I can't seem to find a way of doing this.
Can anyone show be a way of waiting for the product to be gone, without missing the expect (I don't want to use browser.pause for obvious reasons)
Refer this
webElement.waitForDisplayed({ reverse: true });
You can use try catch and basically wait for error. When element disappears from DOM selenium will throw NoSuchElementError and we can use it.
isNotPresent(element) {
try {
return !element.isVisible()
} catch (error) {
return true
}
}
// or wait for element to disappear from dom
waitForNotVisible(element) {
browser.waitUntil(() => {
try {
return !element.isVisible()
} catch (error) {
return true
}
})
}
If you're trying to validate that an element is gone, then using expect is the correct solution, but you should use the Webdriver-expect assertions instead of the chai expect assertions. While chai assertions check the state immediately, the WebdriverIO-expect assertions have the waitFor functionality built inside of it. Here is an example:
let deletedProduct = $(/* your xpath/CSS selector/*);
expect(deletedProduct).not.toBeDisplayed();
The difference between the assertion and using waitForDisplayed with the reverse flag is that some reporters, such as Allure, will report your test as broken when instead the test should be reported as failed. For example, when we ran tests and had the waitForDisplayed, all of our failing tests were marked in yellow. When we use expect, the tests are marked in red.
Here is the documentation for the WebdriverIO Expect matchers. They didn't document the .not method very clearly, but in my example you can see I added the .not before the toBeDisplayed call.
Again, this expect will wait for the timeout specified in the wdio.conf.js, just like the waitFors will.
I have a filter set up as follow to control users login status.
class SecurityFilters {
def filters = {
login(controller:'login|logout|proxy|API|error', action:'*', invert: true) {
before = {
if (!session.isLoggedIn){
switch(controllerName){
case "enroll":
switch(actionName){
...
default:
log.warn "Permission Denied. Default action for enroll."
render(view: '/permissionDenied', model: [message: "You must be logged in to access the enroll system. If you are a consumer, please contact your agent for more information."])
break
}
break
...
}
else {
switch(controllerName){
case "agent":
if (!session.user.isAgent) {
render view: "/permissionDenied", model: [message: 'This portion of the site is only available to agents.']
return false
}
break
....
}// switch
}// else
}// before
...
}// login
}// filters
The problem I am having is that when I run this in development it works fine but when I run it on our QA system it works fine for a while and then suddenly it stops working correctly.
I added logging and I can see that the session information is available in the filter and the session variable (session.user.isAgent) is set correctly (true) but the code inside the if(!session.user.isAgent) gets executed regardless.
I can's seem to find the cause for odd behaviour.
My question is has anyone seen this behaviour before and how did they solve it or have any ideas of where to look for probable cause for the sudden change in the way the filter is working.
Thanks in advance.
UPDATE (02/19/2014):
After adding more logging in an effort to hunt down the cause the filter did not execute the code in the if(!session.user.isAgent) as it was doing before. Now it runs normally and then executes only the render line for when the user is not logged in. The logging still show that the user is logged in and that (s)he is an agent but then it runs the render but not the lines of code above it. It is as if there was a "goto" the render line after it completes checking if the agent is logged in.
Again any information or solution would be appreciated
I've had a few issues with filters and Groovy truth. The problem I was seeing was that no errors were logged, even with aggressive exception catching (i.e. catching Throwable) and the only output in the browser was a blank page. This seems to happen only in Filters- everywhere else the errors get logged.
In my case, the issue was down to Groovy truth. I was trying to set a Boolean attribute on the session, but every time I did this it failed. In the end I had to convert the value to a String, and then set it, and it worked.
I know this isn't a direct answer, but I've been bitten a few times by the above and for example, lazy GString evaluation.
If you're still debugging, I'd log some output showing the underlying Class type of what you think you're dealing with. It may be that when your boolean conditions are evaluated above an exception is being thrown and swallowed. I'd log the actual values of each of your conditional statements to see what they are. Also remove each line one by one, to see if the failure goes away. And/or replace your conditionals with absolute values i.e. true/false to see if the code gets executed. If it does, it points to an error in the current conditional evaluation.
I just migrated my language service from VS2008 to VS2010. Everything works fine except for one important thing: I no longer get LanguageService.ParseSource invoked for ParseReason.Check. It do get a single invoke after opening a file. But after editing code, it no longer gets invoked.
Any ideas what could be causing that?
I also migrated a language service from 2008 to 2010. Can you check if you've fallowed all of these steps?
http://msdn.microsoft.com/en-us/library/dd885475.aspx
I didn't have to do anything else, which I verified by diffing the important files in our depot before and after the change.
I don't know if you ever figured your question out, but have you tried making sure that your Source class' LastParseTime is set to 0 when creating it? I seem to recall some issues with Check not happening unless you manually set LastParseTime to 0 when creating your Source object.
Protip: If you use .NET Reflector, you can disassemble all of the base classes for the LanguageService framework and get a pretty good understanding of how it all works under the hood. The classes you'd be interested in live in Microsoft.VisualStudio.Package.LanguageService.10.0.dll, which should be installed in the GAC. I've found this to be unimaginably helpful when trying to figure out why things weren't working in my own Language Service, and being able to step through the source code in the debugger mitigates almost all the pain of working with these frameworks!
When your Source object is initialized, it starts off with a LastParseTime of Int32.MaxValue. The code that causes fires off a ParseRequest with ParseReason.Check checks the LastParseTime value to see if the time since the last change to the text is less than the time it takes to run a parse (or the CodeSenseDelay setting, whichever is greater).
The code that handles the response from ParseSource is supposed to set the LastParseTime, but as far as I can tell, it only does that if the ParseReason is Check.
You can get around this issue by setting Source.LastParseTime = 0 when you initialize your Source. This has the side-effect of setting CompletedFirstParse to true, even if the first parse hasn't finished yet.
Another way to fix this issue is to override Source.OnIdle to fire off the first call to BeginParse() This is the way I would recommend.
public override void OnIdle(bool periodic)
{
// Once first "Check" parse completes, revert to base implementation
if (this.CompletedFirstParse)
{
base.OnIdle(periodic);
}
// Same as base implementation, except we don't check lastParseTime
else if (!periodic || this.LanguageService == null || this.LanguageService.LastActiveTextView == null || (this.IsCompletorActive) || (!this.IsDirty || this.LanguageService.IsParsing))
{
this.BeginParse();
}
}
I am trying to make firebug break when an error is detected. Specifically, I have some internal checks in my code, like assertions, that I want firebug to stop on when they fail. I have tried a few different ways and wondered what other people do? Here are the ways I have tried:
Put in some invalid code so that if errors out:
function assert(value) { if(! value) dbgbreak(); } // Fails because dbgbreak not defined
This works somewhat, but does not stop the code in such a way that I can see the stack or examine local variables.
Have it throw an exeption:
function assert(value) { if ! value) throw AssertExecption(); }
This is prettier, but still when I track exceptions I can't see the stack or the locals
Put a breakpoint on the assert failure. This works, however, it means everytime I run my code I have to manually put in a bunch of breakpoints.
What do other people do in terms of working with the debugger and asserts, and similar consistency checks?
Have you tried throwing down the "debugger" keyword in your script where you want it to stop?
On the console tab there is a button for breaking on all errors. Turn that on, and it will automatically break when an error occurs.
http://getfirebug.com/wiki/index.php/Console_Panel#Break_On_All_Errors
This is mod_perl2 on Apache 2.2, ActiveState Perl 5.10 for win32.
I override $SIG{__DIE__} and turn on DBI's RaiseError flag, which AFAICT from the docs, should call my override when a database call fails. It seems to almost always, except in one case, and I can't understand why.
My script has an our $page variable, and being mod_perl2, I can get at this from the override like so:
use Carp::Trace;
my $full_trace = Carp::Trace::trace;
$full_trace =~ m/^(ModPerl::ROOT::ModPerl::Registry::.*::)handler .*$/m;
my $page;
if (defined $1)
{
eval '$page = $' . $1 . 'page';
if (defined $page)
{
$json = 1 if defined $$page{json_response};
if (defined $$page{dbh})
{
my $errno = $$page{dbh}->state;
if ($errno ~~ $$page{error_handling}{allowed})
{
# allowed to let it go--no report, expected possible user error at some level that couldn't be caught sooner (usually db level)
my $errmsg = $$page{error_handling}{translation_map}{$errno};
if (defined $errmsg)
{
...
This works fine. Now, within that $page, I have an array ref of 'allowed' error values that I want to do something different with when they come back from the DB. When the DB throws one of these errors, I want to translate it into a user-friendly message, $r->print that in JSON, and stop execution (behaviour A). For some reason, it instead returns control to the script (behaviour B).
Here's the main part of my script:
{
$$page{error_handling}{allowed} = ['22007'];
$$page{json_response}{result} = $page->one_liner("select 'aa'::timestamp");
$$page{json_response}{test} = $$page{error_handling}{state};
}
$page->make_json; # just JSONifies $$page{json_response} and prints it
If I comment out the first line, I get a normal error (handling something unexpected) (behaviour C), which is what I expect, because I haven't added the error that's occurring to the list of allowed errors. What's really strange is, if I cut that first line and paste it into my $SIG{__DIE__} override, it works: the JSON response is overridden, printed, and execution stops before {test} is assigned (behaviour A). Stranger still, I can set {allowed} to any set of numbers, and so long as it contains '22007' in particular, I get behaviour B. If it doesn't, I get behaviour C. Even more strange, I can actually fill my override with anything (warnings, calls to CORE::die, etc.--as long as it compiles) and I get behaviour B still--even though the override no longer contains any of the code that would make it possible! Also I don't get any of the expected results of the calls to warn and CORE::die, just silence in the logs, so I can't even attempt to manually trace the path of execution through my override.
I have restarted Apache2.2 in between every script save. I have even moved the override to the same script file as the script itself, out of the module where it normally is, and commented out the entire module file where the override normally is, and restarted.
If I take out that first line, or take '22007' out of it, I can warn and die and otherwise manually debug all I like, and everything works as expected. What is it about '22007' that it never outputs anything different despite server resets? There are no references to '22007' anywhere else in the entire project, except the translation map, and I can delete it from that file entirely and restart and the result is no different. It's behaving as if it has cached my override from earlier in the day and will never ever forget. It's not a browser cache issue either, because I can add random query strings and the results are no different.
This is the strangest and most frustrating mod_perl2 experience I've ever had, and I've run out of ideas. Does anybody have any hints? The only thing I can think of is that it's a caching problem, yet I've restarted the service countless times.
Since it was the end of the day I thought I would try fully restarting the server computer, and it still didn't change anything. I even, before restarting the server, changed the only line where {state} is assigned to this:
$$page{error_handling}{state} = 'my face'; # $errno;
And yet, the output afterwards had {test} as '22007', which is what it should be only if I had left = $errno intact.
Even if it was, say, the reverse proxy it goes through doing the caching, this situation doesn't make sense to me, since the request can be different. After a full server restart, how can it still be assigning a value that is no longer in the code, i.e., how can it be using my old $SIG{__DIE__} override after a full restart, when it no longer exists in any file?
Update: I also tried changing the allowed errors to '42601' and changing the db call to 'select', which produces that error code, but did not add it to the translation map. It still gives me behaviour B, setting {state} to '42601', so it's not specific to '22007'. Any error code that is put into {allowed}, if that error actually occurs, it's running the old version of the override. Cause an error that's not in {allowed} and it runs the current version. But how does it know whether the current error is in {allowed}, or that that even means anything, before getting to the override? (Because the override is the only place where {allowed} is grepped for the current error.)
This is my temporary workaround, but I would like to solve the mystery and not have to add the extra line everywhere I have a DB call with allowed errors.
package MyModule::ErrorLogging;
sub InsanityWorkaround # duplicates part of $SIG{__DIE__} override for allowed errors
{
my ($page) = #_;
my $r = $$page{r};
my $errno = $$page{error_handling}{state};
if ($errno ~~ $$page{error_handling}{allowed})
{
# allowed to let it go--no report, expected possible user error at some level that couldn't be caught sooner (usually db level)
my $errmsg = $$page{error_handling}{translation_map}{$errno};
if (defined $errmsg)
{
use JSON::XS qw(encode_json);
$$page{json_response} =
{
error => $errmsg,
};
my $response = encode_json($$page{json_response});
$r->content_type("application/json");
$r->print($response);
exit(0);
}
else
{
return 0; # get back to script where {state} can be checked and output can be customized even further
}
}
return;
}
Then my script becomes:
{
$$page{error_handling}{allowed} = ['22007']; # don't be bothered by invalid timestamp error
$$page{json_response}{result} = $page->one_liner("select 'aa'::timestamp");
MyModule::ErrorLogging::InsanityWorkaround($page);
}
This is giving behaviour A.