Guides on mocking API responses, editing HTTP requests and headers, testing error states and debugging the network in the browser, from the tweak team.
It's 2022, and automation is on the rise. The number of software testing tools, libraries, and platforms available increases daily. What different aspects of web applications should you be testing? Which ones should you automate? And when and how should you employ manual testing?
Modern browsers have advanced development toolkits allowing developers to inspect and debug their code in detail. This article will go through the options you have to block HTTP requests with modern browsers.
This article will guide you on mocking a GraphQL request directly in the browser with our extension.
APIs are king in the industry, and GraphQL has changed the APIs game for good with rising adoption. We want to write this article specifically tailored to developers working with GraphQL APIs. Let's begin!
A genuine Chrome browser power user can only reach maximum efficiency using shortcuts. Shortcuts bridge the gap over repetitive tasks that might not be individually super time-consuming. Still, they do add up and crawl up your productivity with time.
If you're getting into JavaScript and frontend development, you've probably come across many use cases where you'll need to fetch data from a remote service endpoint. Depending on the type of application you're working on, this data can come in many different shapes. For single-page applications, it's common to handle remote data in the JSON format and fetch it through HTTP requests. In this article, we want to guide you through some common patterns when handling such requests and share other tips we think are helpful.
Some time back, we've received feedback from a user stating that they could use our browser extension in mobile using the Yandex browser and gave some feedback about usability. We don't develop for mobile, but when we found out it was possible, we improved our import/export flow to allow users to quickly load in a JSON file with many rules and operate with the app while mocking requests with tweak. Let's look at how to achieve it.
Errors handling is part of our work as developers. You can try to ignore them at first, but to offer a good user experience, you don't want your website breaking just because one of the API endpoints decided to give up on you. These days we try to find clever workarounds to run our applications with a graceful degradation strategy. We build software to work in an optimal environment while providing certain fallbacks not to break the experience entirely when there's some disturbance in the system (e.g., lousy network condition, CPU lag, etc.).
This post is a short, hands-on walkthrough: one demo app, one simulated 500, and the fix that gets the UI out of a stuck loading state. For the full list of failures worth testing (401, 422, 429, network errors, timeouts, malformed JSON) with a rule for each, read How to Test Error States in Your Frontend App.
In our "Complete Guide to Test Chrome Extensions with Puppeteer", we've covered all you need to know to get you up to speed on setting up end-to-end testing for a chrome extension. The fact is that many elements of the article can be brought to traditional front-end applications.
To truly deliver to you the complete knowledge we've acquired, we've decided to write this tiny, complementary blog post, where we'll cover ad-hoc topics, let's call it tips & tricks, to help you work with Puppeteer.
Here's what we cover in this article:
All the code referenced in this article can be found in our repo tweak-extension/puppeteer-test-browser-ext.
Writing good documentation is a mission-critical aspect of building software these days. Whether you are writing something for yourself, for the Open Source community, or your company, it's essential to keep things documented for good reasons: