Suggest modification to this talk

Title

Description

Google Analytics, Like Buttons, Twitter Widgets, Olark chat boxes; all examples of third party JavaScript elements that are embedded by users in their websites.

Testing third party code once embedded in a page, is often difficult and cumbersome. Verifying those elements are working properly (or even more basically, are not breaking the page) is difficult to get right. Clients will often not give you access to their page, or allow you to debug 'live', leaving scope for bugs to creep in.

Complicating matters further, other JavaScripts are often competing to execute on the page (sometimes erroring out), and then you have to make this all work cross-browser!
So what is the right approach to take?

I will show you how using a Ruby script to generate and minify my JavaScript, and a Node.js proxy server to intercept responses, I am able to safely inject my JavaScript into the page.

In addition to this, I will show you ways to use Rspec/Capybara to come run regression tests that utilize the proxy, and test my JavaScript while it is live embedded on client pages.

Help us caption & translate this video!

http://amara.org/v/FGYs/

Date

Summarized using AI?

If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.

Show "Summarized using AI" badge on summary page

Summary

Markdown supported

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.

Cancel