Ruby Video
Ruby
An Approach to Developing and Testing Third Party JavaScript Widgets
NA
Nathan Artz
1 talk
#javascript
#testing
#capybara
#ruby
#web-development
Summarized using AI

An Approach to Developing and Testing Third Party JavaScript Widgets

by Nathan Artz

In this video titled "An Approach to Developing and Testing Third Party JavaScript Widgets," speaker Nathan Artz discusses the challenges and solutions involved in creating and testing third-party JavaScript elements embedded in client websites. With the prevalence of tools like Google Analytics, Twitter widgets, and chat boxes, it becomes crucial to ensure that these scripts function properly without disrupting the client’s page. Artz emphasizes the difficulties in testing these scripts due to various factors, including client restrictions on accessing their pages and the complications arising from multiple competing JavaScript elements.

The presentation covers several key points:

  • Nature of Third-Party JavaScript: These scripts typically consist of an embed code that is small and straightforward, paired with a more complex logic code that is responsible for the main functionality.
  • Testing Challenges: Testing third-party code in client environments can be unpredictable, and while one can use Capybara to run tests in a controlled setting, this does not guarantee that the code will perform correctly in a live scenario.
  • Interacting with Client Environments: Artz warns against simple approaches like pasting code directly into the client's console, as this can lead to errors that are not revealed in a controlled testing environment.
  • Proxy Server Solution: To address these challenges, Artz recommends setting up a proxy server using WEBrick in Ruby. This allows developers to intercept responses from client pages and inject their JavaScript, mimicking real-world usage and enhancing testing accuracy.
  • Integrating with Testing Frameworks: After establishing the proxy, it can be registered with Capybara, enabling tests to run as if they were on the actual client site, accounting for various browser behaviors and JavaScript conflicts.
  • Real-Time Demonstrations: This method not only aids testing but also allows for seamless product demonstrations to clients without requiring integration first.

In conclusion, the key takeaway from Artz’s discussion is the importance of testing third-party JavaScript in environments that closely mirror client setups to minimize issues post-deployment. Being proactive about potential problems can lead to successful integrations and a smoother experience for both developers and clients.

Artz's insights aim to equip developers with practical techniques to navigate the complexities of third-party JavaScript effectively, ultimately striving for more robust and reliable web elements.

00:00:14.150 Hi everyone! My name is Nate, and I work at a search retargeting company in the city called Magnetic. We're hiring, so come talk to me afterward; that's my shameless plug. Now, let's talk about third-party JavaScript.
00:00:29.310 All of you kind of know the general concept of third-party JavaScript. You've seen the like button, Twitter widget, Google Analytics, Olark, and tons of advertisements. If you actually inspect the DOM on many pages, you'll see it's polluted with content, and there’s so much going on that it can be difficult to navigate. So, let's take a look at how these third-party JavaScripts function.
00:00:41.010 Generally, these scripts have two parts: the embed code and the logic code. If you've used Google Analytics before, you're familiar with the little code clients put in their websites, which usually loads something more substantial containing all the logic. We want this embed code to be small; you don't want to overwhelm your client with a huge embed code. The logic code is the 'meat' of what we want the code to do. Most of the time, this is where the biggest problems arise, particularly concerning the same-origin policy. However, we will not delve into that today.
00:01:10.590 Let’s pretend that our logic JavaScript looks something like this: we’ll create a text node and append it to the page's body. This is a significant starting point. Now, how do we go about testing this? We give the embed code to the client, and ideally, we want to ensure that it will work perfectly on their page.
00:01:55.470 However, the environment where our code is running can be unpredictable. We can set up our test page, for instance, creating a view in Rails where we place the embed code. We can run tests using Capybara to visit our test page and expect it to have specific content. This approach allows us to ensure that our embed code functions as intended, providing us confidence in the stability of our features.
00:02:25.360 Now, while it's quite satisfying to see our tests pass, we still face uncertainty about how the code will behave in the client's environment. This can be particularly troubling, especially if you are in a startup situation where a lot is at stake. If we hand over this code to the client and it breaks their page, that's not an outcome anyone wants. You’re often left with an uncomfortable feeling, wondering if the JavaScript will work correctly once it's live.
00:03:39.830 One idea that might come to mind is to go to the client's page, open the Chrome Developer Console, and paste our JavaScript code to embed it live. However, this often leads to issues like syntax errors or other problems that indicate our JavaScript is not executing as it should. Even if our tests pass in the controlled environment, we must consider the bigger picture of how it will function on the client's actual page.
00:04:40.080 A core issue with third-party JavaScripts is that most testing doesn't account for different environments. Since each JavaScript may interact differently based on the libraries a client is using, we have to consider potential conflicts, such as competing versions of jQuery. To tackle these issues, we need to ensure that our design accommodates various scenarios and library clashes.
00:05:14.440 One potential solution is to set up a proxy server that can allow us to intercept browser requests. By listening for client page responses through this proxy, we can inject our JavaScript directly into the pages on which it will run. This would allow us to simulate our JavaScript running on the actual client site, providing a level of confidence in our code's functionality.
00:06:34.060 Let's briefly look at how to create a proxy server in Ruby. Using WEBrick, we can create a simple server to listen for requests and inject JavaScript into HTML responses. It’s important to ensure that the response content type is HTML and that it's from our specified host before we inject our script. This technique allows us to give the impression that the JavaScript is running directly on the client’s page, enhancing both our confidence and our clients' experience.
00:07:45.100 Once you've established the proxy server, you can register it with Capybara as a custom driver, directing your tests to interact with it instead of the actual client site. This approach also facilitates testing across various environments, proving useful for debugging in Internet Explorer or other browsers. By configuring your tests correctly, they can run seamlessly in this setup.
00:09:15.110 Having effectively simulated our JavaScript running on the client site, we can ensure everything works as intended during tests. This not only helps with confidence in our JavaScript deployment but also allows for effective demonstration to clients of how their pages can look and function with our scripts.
00:10:10.670 As a side note, using techniques like this can be beneficial for product demos without requiring clients to perform integrations beforehand. After all, it provides an opportunity to showcase how your JavaScript enhances their site with minimum fuss. Furthermore, using tools like PhantomJS can extend functionalities, simplifying the task of managing real-time responses.
00:11:12.350 In conclusion, when developing third-party JavaScript, remember to test in environments as closely resembling the client's setup as possible. You should also think critically about potential issues that could arise, such as API downtime or improper script placements. I hope this technique will empower you to catch edge cases and get the most out of your testing efforts.
00:12:00.339 Thank you!
NA
Nathan Artz
1 talk
Edit
Explore all talks recorded at GORUCO 2014
+3