My Innovative Solution to Test Automation: Attach test execution to the existing browser

A productivity utility that can save several hours every day for test automation engineers, but few people know about it.

Nov 13, 2022

This is included in the “My Innovative Solution to Test Automation and Continuous Testing” series.

When I worked as a test automation engineer (contracting) or consultant, my colleagues were deeply impressed with my productivity. Some labeled me a “10X” or even a “100X” test automation engineer. Many factors contribute to a real and productive test automation engineer. To me, the most important one is to use “Attach test execution to the existing browser” when developing/debugging automated tests for web apps.

First of all, this is not a secret. I wrote about it in my first book (1st edition in 2009): Practical Web Test Automation with Selenium WebDriver, and the article (Jan 2021): Attach Selenium Python Test Steps Against An Existing Browser.

In this article, I would like to share how I came up with this idea, then implemented it, and used it in daily work.

What is “Attach test execution to the existing browser”?

Let’s see it in action (30-second screencast).

Please note, this article is not a sales pitch for TestWise, a testing tool (2010 Ruby Award finalist and listed as the first testing tool in the presentation “Trends in Agile Testing” by Lisa Crispin, co-author of the Agile Testing book) created by me. The foundation of this utility (in TestWise v6) is based on open ChromeDriver’s capability, i.e. any testing tool can utilize it. By the way, you can use TestWise in free mode forever, with just minor inconvenience.

Run one test case and leave the browser open.
See ‘My Innovative Solution to Test Automation: Keep the Browser Open after Executing an Individual Test’)
The test script failed.
This is usually far more common than success during the development phase.
Select one or more test steps (in TestWise) and run them in a special mode “Run Selected Script Against Current Browser”.
Somehow (I will explain later), TestWise will run those selected steps in a special file (such as debugging_spec.rb. or debugging_test.py, depending on the scripting language) against the (opened) browser window.

For detailed steps, check out my other article “Attach Selenium Python Test Steps Against An Existing Browser”. Please note, this is a generic technique. The video shows this feature for a Pytest script. It also works for JavaScript, and the best is in Ruby. I implemented this feature in 2007, and have been using this many times every working day ever since.

Experienced testers would understand the massive benefits of this feature. If you haven’t realized it yet, read on)

Why “Attach test execution to the existing browser” is so helpful?

Over my 12 years+ working as a test automation consultant, I found that no tester has realized that he/she can actually use this feature during work to save them hours every day. Here is how they typically develop/debug a test script.

Develop the first draft version
(manual scripting or with the help of a recorder)
Run the test script, and it fails.
(for argument’s sake, there are 100 test steps, failed step 13)
Inspect the test output.
(often after the browser closed)
Open a new browser to navigate up to Step 13 manually. Analyze and modify the test script.
Run the test script again.
(Maybe another failure at step 25)
…
Until all steps pass.

The productivity is very low because this poor tester needs always start from Step 1.

In addition, for a new test step during the test script development phase, a tester might need to experiment with different locators (to find an optimal one for accuracy, execution reliability, and efficiency). It will be a huge time-wasting (and frustrating) exercise if every test run restarts from the beginning every time.

For enterprise apps, a typical end-to-end workflow, even in automated scripts, takes several minutes. This means, a trial of one test step means a wait of serveral minutes. No wonder that real test automation (except of a few simple demo tests) was rarely implmented in large companies (money is not the problem).

From my observation, that is one of many technical reasons that many Test Automation attempts failed. The testers only care about getting the test scripts working once or twice. Some of the testers know that their choices of locators are not good, but there will be too much hassle to refine them. Check out my article: Working Automated Test ≠ Good Reliable Test.

“If a common task is hard to do, we do it less often” — Zhimin Zhan

During my consulting engagement (over 15 years), every test automation engineer I met thought it was normal to restart from Step 1 on every test run. After I showed them a simple and much better way in TestWise: to attach executions of the selected test steps to the last browser window, they all loved it. I remember one tester told his manager on the first day under my mentoring: “I completed the XXX end-to-end test case this afternoon (about 3 hours); A similar test took me a whole week last month (using WebDriverIO in JS)”. This tester was still new to Selenium Ruby and TestWise, he was even more efficient the next day (his 2nd day under my coaching).

As I mentioned earlier, I have been using this technique since 2007 to help my clients and my own projects. The new-to-automation testers like it (easy) too, and they are very comfortable using it after attending my one-day test automation training.

Watir-Classic’s Attach Browser Feature was not available on Selenium WebDriver

I started real UI test automation with Watir in 2006 (see My Test Automation Journey). Please note, Watir then (renamed to watir-classic) was different from the current one. Watir-Classic had an important feature: Watir Attached an existing IE window, which came with the framework.

However, this was a special Windows OLE feature that only worked with IE on the Windows platform. When Selenium WebDriver was released (in 2011), I was desperately looking for this feature in Selenium but had no luck. I was not alone, as you can see in this Selenium Issue “Allow webdriver to attach to a running browser” on Github.

The official reply by the Selenium Team was “Not Feasible”.

I implemented this feature in TestWise 3

Back in 2011, I predicted that Selenium would take over Watir to dominate web test automation (check out my article: Why do I prefer Selenium (Ruby) over Watir?) in just a matter of time (the reason is simple, WebDriver was going to be a W3C standard, and now is). As I needed to use the “Attaching browser” feature many times every working day, I simply would not be able to continue to do test automation using Selenium without it!

One day, a thought came to me. Given the framework (Selenium WebDriver) was possible, what about the tool? At that time, I had been using my own TestWise (a functional testing IDE) for a few years, which supported Watir. Adding support to Selenium would not be hard. The deciding factor was whether “Attach the browser” could be done within TestWise.

The answer came up quickly. By reading Selenium developers’ comments on this, it seemed that the issue was ‘different processes’. I realized that one disadvantage of Ruby 1.8: the execution of external programs within the same process. This might be my advantage in implementing this feature.

I started a test script by using the driver object in a global variable.

@driver = $driver = Selenium::WebDriver.for(browser_type, browser_options)

global variables (in the example, $driver is shared by all ruby code in the same process).

2. To attach the browser, I moved the selected test steps into a special debugging test file, debugging_spec.rb

# in debugging_spec.rb  it "Selected" do
    use_current_browser 
    driver.find_element(:id, "username").send_keys("agileway")
  end

When executing this special test script file, there will not be a launch of a new browser. Instead, it will call a function: use_current_browser , which will simply return the saved global driver instance back.

def use_current_browser
   @browser = @driver = $driver
end

However, there are two limitations compared with built-in support in the framework.

It can only attach the browser instance started by TestWise.
It won’t be a problem for TestWise users. Read my other article: My Innovative Solution to Test Automation: Keep the Browser Open after Executing an Individual Test
It can only run in a special debugging test script.
To make it easy, I added a ‘new execution mode’ in TestWise, I named it “Run Selected Scripts Against Current Browser”

*“Run Selected Scripts Against Current Browser” in TestWise 3 and 4.*

3. Entered the “debugging mode”

Once you are in this mode (I call it TestWise debugging mode, which is different from the usual programmers’ code debugging), you are free to edit the test steps in this special ‘debugging test case’ and try the test steps quickly and repeatedly.

Yes, you can even perform operations on the web page manually and rerun the test steps in this debugging mode.

A total reimplementation in TestWise 6

TestWise 3 (and later version 4) helped me to be productive in developing Selenium WebDriver for a few years until 2017. Selenium WebDriver 3 dropped the support for Ruby v1.8, which was fair enough. However, TestWise 4 depended on Ruby 1.8.

This limitation was not set by me. I developed TestWise using wxRuby (a port of wxWidgets), a GUI library. wxRuby was deprecated in 2011. It still works well but is limited to Ruby 1.8.

When Selenium 3 was released (October 2016), I had to download its ruby binding and perform quite a large-scale change to make it still work with Ruby 1.8 for every minor release. It was quite some effort, every time. I did this for me and my clients (including free community edition users) to enable us to continue to use this “Attach the browser” feature.

This situation lasted over a year or two. Frankly, I wanted to give up a few times as there was no hope. I knew the next Selenium update (v4) would end this. The only reason that kept me going was that I had created several web apps and I needed test automation to keep my high development productivity.

Without the capability of Continuous Testing: executing the whole suite of Selenium End-to-End (via UI) Testing multiple times of day, I could not do daily production releases. I might need to start to log defects, …, etc. Those activities might be acceptable for some teams, but not for me. I have been developing/maintaining several apps in my spare time, including TestWise, SiteWise, ClinicWise, BuildWise and WhenWise (all with commercial customers). Furthermore, I also do writing, and above all, I still want quality family time. Without the “Attach browser” feature alone, I knew, sooner or later, I would lose all my apps.

In desperation, I tried the following

develop my own port of wxWidgets to Ruby
develop TestWise v5 in Python, using wxPython
(Python is quite similar to Ruby, and wxPython is still well maintained)
develop TestWise v5 in Java, using a new UI
(I am quite a good Java Programmer)

I made some progress on the above but realized it would be too much effort for me to handle them as a part-time project.

Then, one day I read an article that stated that “C++ 11 is the new C++”. A crazy thought came to me, “Why not go directly to the root? Develop TestWise in C++”. I coded in C++ briefly in my early career. To be frank, I feared using pointers, memory management, …, etc. But I love test automation, love developing my own apps, love daily production releases, …, etc. Without a high-productivity testing tool such as TestWise, all the above will be in vain.

On 2018–07–01, I started a total rewrite of TestWise in C++. Long stories short, 18 months later, TestWise v6 was released. The new TestWise supports “Attach the browser” (of course, the usage is the same), and it is much faster (launch < 3 seconds) and better looking.

How “Attach the browser” is implemented in TestWise 6?

Start Chrome (from test scripts) with --remote_debugging_port .
I don’t know when this option was made available.
In use_current_browser in the special debugging test script, connect the browser with the option debuggerAddress = 127.0.0.1:%{remote_debugging_port}

def use_current_browser
  # ...
  browser_debugging_port = last_session_browser_debugging_port
  the_chrome_options.add_option("debuggerAddress", "127.0.0.1:#{browser_debugging_port}")
  @driver = Selenium::WebDriver.for(:chrome, the_browser_options)
end

Technically speaking, you can achieve “attach browser” in test scripts without any testing tools, only a minor code change is required (to switch the execution mode). However, in reality, you do need a tool to do that, as this will be used frequently. (also, support of POM is also required. If using TestWise, all is covered. Again, you may use TestWise in free mode forever)

“If a common task is hard to do, we do it less often” — Zhimin Zhan
I started showing the “attach the browser” for Selenium in 2011 (at conference presentations, training, books, and articles). Some “smart” developers / test engineers immediately introduced this to their teams, using raw scripts (--remote_debugging_port and debuggingAddress ). After initial glory, to my knowledge, their test automation attempts all failed. Initially, the team member thought it is very cool, but did not use often. The reason, for this frequently-used feature, you do need it be easy and quick as in TestWise. Most of those “smart” engineers did not want others to know they learnt this trick from TestWise or my presentation/books.

One advice to experienced engineers: try to follow practices in this workbook exactly, at least before you being comfortable to develop/maintain 50 tests (level 2 of AgileWay Continuous Testing Grading). Building from there, you can explore and impress your boss and colleagues.

If you have chosen a testing tool (or programming editor) other than TestWise, make sure to invest some time to add the “Attach the browser” feature to your tool.

FAQ

I am aware of this and used it before, but it is not as great as you said.
As I said, --remote_debugging_port and debuggerAddress options are now available for any tool vendors to implement this feature. There might be a library or a tool with this capability, easy-to-use is another important factor (due to its high-use frequency). By the way, in my recent Web Test Automation Workbook bite-sized coach sessions, two IT laymen started using this feature comfortably in the 4th exercise.
Also, does it support POM steps? (TestWise does)
You claimed TestWise with the “Attach browser” feature made you very productive, can you give us a comparison to others?
I completed two Test Automation POC (proof of concepts) in 3 and 5 days. The planned time (set by the tech lead and management) of both POCs was three months.
You can find some screenshots of testing reports (of my apps) in some of my articles.
I can see that “Attach browser” is very useful. I doubt is of the utmost importance to software development as you described.

Achieving real Agile/DevOps is rare. High-productive end-to-end test automation is a must in real Agile/DevOps. Besides tools, there are technical abilities, such as Maintainable Automated Test Design, Functional Test Refactoring, Continuous Testing (not CI/CD), …, etc.

But if the test automation engineers were even struggling with writing automated tests, you can forget about Test Maintenance and Continuous Testing, both of which are much more challenging.

The Agile Way

Discussion about this post