We are proud to release Wicked Good XPath, a Google-authored pure JavaScript implementation of the DOM Level 3 XPath specification. We believe it to be the fastest XPath implementation available in JavaScript.

To use Wicked Good XPath, simply download the wgxpath.install.js file and include it on your webpage with a script tag. For example:
<script src="wgxpath.install.js"></script>

Then call wgxpath.install() from your JavaScript code, which will ensure document.evaluate, the XPath evaluation function, is defined on the window object. To install the library on a different window, pass that window as an argument to the install function.

Despite the growing popularity of CSS selectors, XPath remains a useful mechanism to locate elements in an HTML document. It has particularly heavy usage in the context of frontend web testing tools like Selenium and Web Puppeteer. Sometimes there is simply no way to reference an element on the page other than with an XPath expression.

For those who have never used XPath, here is a taste:

On a Google search results page, the XPath expression //li[@class=”g”][3] identifies the third search result. Here is a snapshot from the Chrome extension XPath Viewer showing the third result selected when that expression is used.

A key challenge when using XPath, however, is that it is not natively supported on every browser. Most notably, Internet Explorer does not provide native XPath support for HTML documents. As a result, users turned towards pure JavaScript implementations of XPath. In 2005, Google engineers released AJAXSLT, which included a correct, but slow, XPath evaluator. Running web tests on IE using AJAXSLT was time-consuming.

Fast-forward to 2007, Cybozu Labs released JavaScript-XPath, a new JavaScript XPath implementation that was 10 times faster than AJAXSLT. The web testing tools began using it instead, and life was good... for a while. The JavaScript-XPath quickly fell out of maintenance, and bugs became tough to get fixed. Also, since it wasn't written in Google Closure, it was tricky for us Googlers to integrate into our JavaScript applications. A rewrite was necessary.

However, we went beyond merely porting the library to Google Closure and fixing a couple bugs. We identified some significant additional performance improvements, such that our version runs about 30% faster than the original. On top of that, the Closure compiler was able to minify our code down to a mere 25K, 40% smaller than JavaScript-XPath's 42K. Finally, the code is structured and documented in a way that we believe will make future maintenance quicker and easier.

We would like to thank our two Google interns, Michael Zhou and Evan Thomas, for doing the bulk of the development on this project.

By Greg Dennis and Joon Lee, Google Engineers

We are pleased to announce the open source release of a Javascript coverage analysis tool called ScriptCover. It is a Chrome extension that provides line-by-line Javascript code coverage statistics for web pages in real time without user modification of the site. Results are collected when the page loads and continue to be updated as users interact with the page. These results can be viewed in real time through a reporting tool which highlights the executed lines of code for detailed analysis. ScriptCover is useful when performing manual and automated testing and in understanding and debugging complex code.

Short report in Chrome extension popup, detailing both overall scores and per-script coverage.

Sample of annotated source code from the detailed report. First two columns are line number and number of times each instruction has been executed.

We envision many potential features and improvements for ScriptCover, e.g.:

• support other coverage metrics, e.g. path coverage and condition coverage
• support richer reports and exporting to HTML and XML
• submit Javascript coverage statistics to a server and analyze combined statistics for selected users, dates, etc.
• map user actions to related Javascript code

Want to get involved with ScriptCover and make it better? Join the team! To get started, visit our project page, join the community, read documentation and download the code.

By Ekaterina Kamenskaya, Software Engineer in Test, Google

Can you spot the error in the following webpage?


Unless you are one of the 56 million Internet users who read Arabic, the answer is probably no. But BidiChecker, a tool for checking webpages for errors in handling of bidirectional text, can find it:


Oops! The Arabic movie title causes the line to be laid out in the wrong order, with half of the phrase "57 reviews" on one side of it and half on the other.

As this example demonstrates, text transposition errors can occur even if your web application is entirely in a left-to-right language. If the application accepts user input or displays multilingual content, this data may be in one of the right-to-left languages, such as Arabic, Hebrew, Farsi or Urdu. Displaying right-to-left text in a left-to-right environment, or vice versa, is likely to cause text garbling if not done correctly. So most user interfaces, whether left-to-right or right-to-left, need to be able to deal with bidirectional (BiDi) text.

Handling BiDi text can be tricky and requires special processing at every appearance of potentially BiDi data in the UI. As a result, BiDi text support often regresses when a developer adds a new feature–and fails to include BiDi support in the updated code.

Called from your automated test suite, BidiChecker can catch regressions before they go live. It features a pure JavaScript API which can easily be integrated into a test suite based on common JavaScript test frameworks such as JSUnit. Here's a sample test for the above scenario:


// Check for BiDi errors with Arabic data in an English UI.
function testArabicDataEnglishUi() {



 // User reviews data to display; includes Arabic data.



 var reviewsData = [



 

 {'title': 'The Princess Bride', 'reviews': '23'},


 

 {'title': '20,000 Leagues Under the Sea', 'reviews': '17'},


 

 {'title': 'ستار تريك', 'reviews': '57'} // “Star Trek”



 ];





 // Render the reviews in an English UI.


 var app = new ReviewsApp(reviewsData, testDiv);


 app.setLanguage('English');



 app.render();







 // Run BidiChecker.



 var errors = bidichecker.checkPage(/* shouldBeRtl= */ false, testDiv);



 // This assertion will fail due to BiDi errors!



 assertArrayEquals([], errors);

}

We’ve just released BidiChecker as an open source project on Google Code, so web developers everywhere can take advantage of it. We hope it makes the web a friendlier place for users of right-to-left languages and the developers who support them.

By Jason Elbaum, Internationalization Team

The Android development tools provide developers with a host of tools for creating fun, useful and compelling Android applications. Included in this tool-set are various testing tools that make it easier to ensure the quality of the applications. One tool that has been missing, however, is a mocking framework.

Objects Mocking is a common technique in the tester’s skillset. Mocks are simulated objects which mimic and take the place of real objects by replaying pre-recorded behavior. They are used to quickly build more focused tests that reflect better the behavior of the tested objects. This is achieved by breaking long object construction chains, isolating interesting behavior to tighten a test’s focus. “Mocking” various services such as a network connection, a database or even a per-use credit card charging service (the kind you don’t want to stress-test with your personal credit card number!) makes it possible to test real external interactions without ever touching the real thing.

Here at Google, we use mocking frameworks a lot when writing Java tests (for the reasons above, and more) but unfortunately, the solutions available only provide limited mocking capabilities for Android testing.

That is, until now:

Android Mock has been written as an extension of EasyMock to allow for the mocking of Java Interfaces and Classes on Android’s Dalvik VM. Check out the resources for how to use it and how to write tests, then get mocking.

By Stephen Woodward, Software Engineering Team

We've just released Stressful Application Test (or stressapptest), a hardware test used here at Google to test a large number of components in a machine. The test tries to maximize random traffic to memory from processor and disks with the intent of creating a realistic high load situation. The source code is available under the Apache license.

stressapptest may be used for various purposes:

• Stress test for machines.


• Hardware qualification and debugging.


• Memory interface test.


• Disk testing.

The stressapptest team (from left to right): Matthew Blecker, John Huang, Raphael Menderico, Nick Sanders, John Hawley and James Vera

Photo credit: Taral Joglekar

stressapptest is a user space test, primarily composed of threads doing memory copies and direct I/O disk read/write. Since many hardware issues reproduce infrequently, or only under corner cases, the idea behind the test is that by maximizing bus and memory traffic, the number of transactions is increased, and therefore the probability of failing a transaction is increased. It loads the memory with specially-designed patterns that cause the signal lines to rapidly switch between 1 and 0, drawing the maximum amount of power and cause maximal noise on the nearby voltage rails. Noise on voltage rails and coupling with other nearby lines is likely to cause signaling problems on marginal lines. Also, given a probability of any signal level transition failing, these patterns have the most memory transitions per period of time, and are thus more likely to exhibit a failure.

This test was designed to test all memory available on a machine, which is not guaranteed with the execution of a CPU-intensive application (for instance, compiling the kernel on multiple threads). Moreover, it is focused on testing the memory interface and connections, not the memory internally, like memtest86. As a consequence, Stressful Application Test will detect errors not detected by regular memory tests or extended executions. A comparison with some other memory reliability tests showed that about 20% of the DIMM-related failures detected on the machines tested were only detected by Stressful Application Test, and it was capable of reporting 70% of all DIMM errors detected by all tests.

We hope this software will be useful to system administrators who need to diagnose and repair DIMM or other components. We look forward to your questions and feedback in our discussion group. Happy hacking and may your testing be less stressful!

By Raphael Menderico, Software Engineering in Test Intern, Platforms Team

Can you spot the bug in the following piece of Java code?

/** Maintains a list of names. */
public class NameManager {
  private List<String> names = new ArrayList<String>();
  /** Stores a new list of names. This method is threadsafe. */
  public void setNames(List<String> newNames) {
    synchronized (names) {
      names = new ArrayList<String>();
      for (String name : newNames) {
        names.add(name);
      }
    }
  }

(Hint: the method setNames() is synchronized on the names field, but that field is then modified to point to a new object.)

OK, so spotting the bug was easy. But how would you write a Unit Test to demonstrate the problem? You would need to have two or more threads calling setNames() simultaneously, but you still don't have any control over how the threads will be scheduled.

Enter Thread Weaver, a test framework that lets you control thread execution. By setting breakpoints in your code, you can stop one thread at exactly the point that you want, and then allow a second thread to run. This allows you to write repeatable multi-threaded unit tests, without relying on the thread scheduler.

Thread Weaver is released as an open source project under the Apache license, and is available on Google Code. Many examples can be found in the initial documentation. If you have comments or questions, please see our discussion group. Happy testing!

Ed. Note: Post updated with corrected formatting.

By Alasdair Mackintosh, Software Engineering Team

By Justin TerAvest and Stewart Miles, Platforms Engineering Team

We're pleased to announce the initial release of the Open Source project Cmockery, a lightweight library to simplify and generalize the process of writing unit tests for C applications. This testing framework tries to keep testing quick and simple by avoiding complex compiler features such as variadic macros or C99 features that may not be available in older compilers. Secondly, Cmockery doesn't assume the availability of the standard C library in code modules being tested, which makes it useful in code for embedded systems that isn't executed within the snug environment of a typical operating system.

To find out more, check out the code and start writing unit tests for your C applications, please visit the project homepage. We also welcome your feedback in our discussion group.

By Leslie Hawthorn, Open Source Team

When Guido van Rossum mentioned that one of our Google Highly Open Participation Contest™ (GHOP) students, Benjamin Peterson, was interested in doing a more extensive project on Python testing, we were happy to help. Benjamin Peterson recently finished his work on testing the CPython core and was kind enough to send us this report.

Benjamin writes:

With sponsorship from Google, I've just spent the summer working on the tests for the CPython core.

I spent a lot of time working on the test driver, regrtest.py, in order to make implementing features easier in the future. One of the ugliest parts of regrtest.py is that it kept a list of all the tests that could be expected to be skipped on a platform, so I moved this logic to the tests themselves. In the end, I wasn't able to fully remove Python core related logic from it, but the removal of expected skip lists simplified the program greatly.

I made command line use of regrtest easier in several ways. When specifying tests, one no longer needs to give the test_ prefix. I also implemented test selectors which allow a range of tests to be specified. For these new features, I added unittests. Another major feature is that regrtest automatically writes a list of the tests run, with failures and skips noted, after each testing session. The session can be rerun exactly the same way on another computer by reading the file with the -f option.

Finely grained test skipping is another important feature. New decorators in test_support allow whole test cases and individual methods to be skipped. Decorators range from the generic skip_if, which skips when the condition passed to it is true, to skip_on_platform, which skips if any of the listed platforms are in sys.platform. I hope that some form of these decorators can be included in unittest eventually.

I visited each of the 361 tests to upgrade it to use my new features. I was able to consolidate some tests with each other. A few tests that escaped earlier sprints were converted to unittest.

I really had a fantastic experience this summer. I learned an incredible amount from nice, patient people and look forward to next year! Many thanks to Georg Brandl, my awesome mentor, Guido van Rossum and the rest of the Python core development team, and Google's Open Source Programs Office for making this possible.

And in other news Python and GHOP, Zachary Voase, another Python GHOP student, recently attended Campus Party in Valencia, Spain, and spoke about his experiences in the contest. You can check out the video of Zack, along with some of our Google Summer of Code™ students, on YouTube. (Campus Party site and video are both in Spanish.)

So you just finished writing a really sweet Python application, and now it's time to do some testing. Or wait, better yet, you're going to write the tests first, then write your application code. It's probably time to pick a mock object framework to make writing tests easy; you definitely don't want to waste your time writing mocks by hand! Well, after many requests from former interns and Googlers working on Open Source projects, I'm happy to announce that now you have another option: Mox!

Mox is a mock object framework for Python developed at Google (and used in hundreds of projects here) that uses the record-replay-verify paradigm you might already be familiar with from library's such as Java's EasyMock. You create a mock object based on a class, record the expected behavior by calling methods on the mock just like a regular instance, then you put the mock in replay mode and run your test. After your test is complete, you can verify that the code-under-test interacted with the mock as expected.

Why would you want / need a mock object framework? In many cases you want to be able to test portions of your code without setting up all of your applications dependencies (databases, file systems, or even just other complex parts of your application). Mox allows you to easily create mock versions of your dependencies (Python classes, even modules) for use in tests. These mock versions only need to know about how they are called (which methods with what parameters), and what they should return. For example, instead of starting up a local copy of MySQL and populating the database with test data just to test that your InsertCustomer method works (or fails elegantly), now you can use Mox to simulate calls to, and responses from the database.

m = mox.Mox()
mock_db = m.CreateMock(database)
new_pk = 12356;
mock_db.OpenConnection()
mock_db.Execute("INSERT INTO Customers (fname, lname, email) VALUES
('Sandy', 'Smith', '[email protected]'").AndReturn(new_pk)
mock_db.CloseConnection()
m.ReplayAll()

p = PersistenceLogic(mock_db)
actual_pk = p.InsertCustomer('Sandy', 'Smith', '[email protected]')

m.VerifyAll()
assertEquals(new_pk, actual_pk)

Mox has several other advanced features, like the ability to temporarily stub out any object or module with a mock object — even parts of the global environment.

We always love to hear what you think. Please join the Mox discussion group and share your thoughts with us.

By Steve Middlekauf, Software Engineering Team

By Zhanyong Wan, Software Engineer - Testing Technology Team

We Googlers are quite excited about testing, but we're even more excited to share the tools we've created with the community. We've Open Sourced our Google C++ Testing Framework, Google Test, under the New BSD License. Google Test is based on the popular xUnit architecture and works on a variety of platforms, including Linux, Mac OS X, Windows and embedded systems like Symbian and Windows CE. You can find full details on the Google Testing Blog. We welcome your feedback, so please join the Google Test Discussion Group and share your thoughts with us!

By Leslie Hawthorn, Open Source Team

You may recall that Charlie Gordon and Jimmy Berry were named two of Drupal's runner ups for the Google Highly Open Participation Contest (GHOP). What you may not know is that both of these gentleman are highly skilled testing aficionados, both of them continuing to improve Drupal long after the contest has ended. When we heard that our Drupal friends were organizing a Testing Sprint in Paris, we were excited to hear that years of desire for better testing had gelled into plans for a weekend of concerted community effort in this area.

We were even more excited when we heard that Charlie and Jimmy were counted among the key participants for the sprint, and we were happy we could assist them with their attendance at the sprint. While we wish we could have joined them in the City of Light, the most exciting part of all is hearing from Charlie and Jimmy about all the great things they managed to accomplish in just two days, in addition to all of the great work they've been doing for Drupal since GHOP. Both of them were kind enough to send us along updates on all things Drupal, testing and sprinting.

Charlie writes:

A few weeks ago, Google sponsored a trip for me and Jimmy Berry (18) to Drupal's Code Sprint in Paris. It is safe to say that without Google's sponsorship, I would not have been going. This opportunity was incredible, both for myself, Jimmy, and the Drupal community as a whole. Drupal is a Content Management Platform which has recently decided to make the switch to test driven development. Once all of us were there in Paris, we did our best to make this dream a reality. The results were superb— Drupal now has an automated testing system in its core, and we have functional tests written for nearly all of the Drupal core. This is truly an amazing achievement that Drupal has been striving for for nearly three years, but this sprint has made it into a reality. It is truly awesome to be involved in such a vibrant open source community with so much support. I'm only fifteen years old, but my involvement in open source has led me to go places and do things I would never have dreamed I could do. If someone had told me a year and a half ago, before I started working on open source, that in less than two years I would be sponsored by Google to go to Paris to help improve an automated testing framework in order to get it into the core a content management system called Drupal, I wouldn't have thought it possible.

Drupal Testing Sprinters
(clockwise from top left: Jimmy Berry, Dries Buytaert, Charlie Gordon, former Google Summer of Code™ student Rok Zlender, Douglas Hubler and Miglius Alaburda)

Jimmy shares these thoughts on graduation from GHOP, life after the contest, and moving on to become a Google Summer of Code student:

Since the end of GHOP I have become increasingly involved in the Drupal project. After much encouragement and generous donations I was able to attend Drupalcon Boston 2008. At the conference I spoke in two sessions, one about GHOP and the other regarding automated testing of Drupal, an area where I'd become particuarly involved. My contributions from GHOP had placed me at the forefront of the push to improve automated testing of Drupal, and it was quite rewarding to see Dries deliver his State of Drupal keynote in which he detailed plans to have 100% test coverage of Drupal 7, especially since his talk occurred right after our testing session.

The newly increased priority and accelerated timeline meant that much work would need to be done in the next several months. Upon returning home I got started and was soon given the opportunity to become the maintainer of the SimpleTest module, the focus of automated testing development. I was excited by the opportunity to play an influential role in the development of Drupal 7 and accepted heartily. Given the authority to make code changes and incorporate contributed patches, I accelerated the rate of development. SimpleTest soon saw an enormous amount of change and inched ever closer to inclusion in Drupal core.

The proposed Paris testing sprint started to become a reality and I began raising funds and further preparing SimpleTest for the sprint. Work continued furiously over the next several weeks. Thanks to generous donations from individuals and Google I received the necessary funding to attend and the sprint took place in Paris, France from April 19th to 21st. We worked for two days before resolving the outstanding issues that blocked SimpleTest's entrance into the core, but our efforts paid off once SimpleTest was committed. It was a great experience to work with a group of dedicated developers to accomplish goals.

I plan to continue my contributions to Drupal through the Google Summer of Code. My Usability Testing Suite was accepted as a project for the 2008 summer. I am looking forward to working on the project and seeing it put to good use. None of this would have happened without the GHOP initiative and all those involved, so my thanks to all of you.

Many thanks to Charlie and Jimmy for sharing their experiences. As we like to say here at Google, debugging sucks, but testing rocks! We're glad we could help Charlie, Jimmy and the whole Drupal community rock even more than they already do.