Pro-Tip: What are you waiting for?

Again, for some of you veterans out there, this might be an old-hat tip... so, move along, nothing to see here.

This is something that I've run into with almost every application I've had to automate over my years. And, honestly, it doesn't really matter WHAT tool you're using, you're going to run into the same problem.

What problem is that?

As the old joke goes, what's the difference between a good comedian and a bad comed--  TIMING!

The Problem

I'm currently working on integrating a number of test cases that someone else developed into the overall framework structure of our larger testing suite. Generally speaking, they are well constructed test cases and, when running stand-alone, they tend to run pretty smoothly.

However, in my integration process, I'm running into a number of situations where the test case appears to be working well, but then something just stops working. Inevitably, it's because some action is attempted to be performed on an object that is, for whatever reason, not responding properly to actions. 

In my case, there are functions that are being performed against a web page where data is being entered on a form and the "Save" button is being pressed.  The very next action is to click the "Exit" button on the form to go back to a previous screen. Normally, for a web page, this would simply be a matter of using the Wait method on the page to wait for the page to load. But the architecture of the application undertest isn't quite so nice to me.  Basically, while the data is still being saved to the database, the Page.Wait returns and the Exit button is attempted to be clicked because, after all, it exits, is enabled, is present on screen, and is not overlapped by anything else.  And yet... the button gets clicked (at least my log says it does) but the Exit function never executes and my test script fails because I'm not where I expect to be.

The Standard Solution

Myself and many others would then, at this point, direct the poster to read the following article and attempt to implement one or several of these methods in order to "Wait" until the button is ready to be clicked.

https://support.smartbear.com/testcomplete/docs/app-objects/common-tasks/waiting-process-or-window-activation.html

And, normally, we'd be right in this.  Most of the time, this works.  However... in my case, this doesn't work. As mentioned above, there's nothing to be checked about visible, enabled, exists, visibleonscreen, etc, that I can check on this button. It, for all intents and purposes, is ready to be clicked... and yet, it's not.

The Trick

And this is where sometimes you just need to sit and stare at the computer screen for a while. After a while of frustration trying the standard tricks of increasing timeouts, adding Wait methods, etc., I decided to just sit and watch the screen and see what is going on.  That's when I noticed something that I always knew to be there but never really considered.

When the "Save" button is clicked (for that matter, there are MANY other actions that prompt this same response), there's a little panel that displays in the middle of the web page that says "Loading" while the rest of the web page is "greyed out".  Note, it is greyed out, but not overlapped, disabled, etc... I can't CLICK on anything, but it's still there. So, what I observed is that, those times when the "Click" on the exit button was failing was in those split moments where Page.Wait returned and that loading form was still visible on screen.  It didn't happen often, but often enough to be annoying.

In investigating this form, I noticed that the developers weren't instantiating or destroying this form at points in the code.  It was, technically, always present.  When it wasn't being displayed on screen, it's height and width would be set to zero.  When it is to be displayed, it has those values greater than zero.  This meant that I couldn't just do a "Visible" or "VisibleOnScreen" or "Exists" check on this form, I needed to actually check to see if the form had a width greater than zero.  If it did, I would delay the test briefly until the width got set back to zero.

And bingo... there it is.  Now my test runs without fail. 

Why am I sharing this with you? The reason being is that sometimes the standard solutions don't always work. The only answer to be able to find a solution is to actually spend the time and elbow-grease to watch the test as it is executing and use those observational skills that every good software tester has to see EXACTLY what is happening and to build a creative solution around it.