Coder Legion - Recent posts tagged test

Top Staging & Sandbox Tools to Test Site Updates Before Going Live

Wed, 28 Oct 2026 18:04:23 +0000

Updating a website without testing the changes first can put an entire business at risk. A new plugin can break a WordPress installation. A theme update can damage a page layout. A change to a database can affect customer records, while an application deployment can introduce errors that prevent users from completing purchases or submitting forms.

Staging environments and sandbox tools help website owners identify these problems before changes reach the live site. They provide separate environments where developers can install updates, test code, review designs, and check functionality without directly modifying the production website.

For businesses that depend on their websites for sales, customer communication, publishing, or daily operations, testing before deployment is an important part of website maintenance.

Several platforms offer different approaches to this process. Managed WordPress hosts provide staging environments within their hosting dashboards. Web development platforms create temporary previews for new code. Local development tools allow developers to build and test websites on their computers.

The best option depends on the website's technology, hosting arrangement, development process, and security requirements.

What Are Staging and Sandbox Tools?
A staging environment is a separate copy of a website or application used to test changes before deployment. Depending on the platform, it may include copies of the website's files, database, configuration, and other components required to reproduce the production environment.

A sandbox is an isolated environment where developers can experiment with code, software configurations, integrations, or other changes. Some sandbox tools focus on individual components, while others support an entire website or application.

These terms overlap, but they are not always interchangeable. A staging environment usually aims to reproduce the live website closely. A local development environment supports building and testing on a developer's computer. A preview deployment publishes a version of an application to a temporary URL so developers, clients, or other team members can review it.

The main purpose is the same: identify problems before releasing changes to users.

A suitable testing environment can help teams evaluate plugin compatibility, check page layouts, test forms, inspect application behavior, and review changes before deployment. However, a staging site does not automatically reproduce every production condition. Differences in server configuration, traffic, external services, payment integrations, and database contents can affect test results.

Kinsta Staging Environments
Kinsta provides managed WordPress hosting with staging environments that allow website owners to test changes separately from their production websites.

Its standard staging environment is available for WordPress installations, although custom plans may limit the number of environments available. Kinsta also offers premium staging options for customers who require additional environments or resources for more demanding development and testing tasks.

The platform is useful for website owners who want to test WordPress updates without building a separate testing infrastructure from scratch.

Key features
Separate staging environments for WordPress installations.

Testing for WordPress core updates, themes, plugins, and custom code.

Options for moving changes between staging and production.

Selective deployment options for files, database content, and specific database tables.

A managed hosting dashboard for handling environments.

Kinsta's selective deployment options can be particularly useful when a developer needs to transfer specific changes rather than replace every component of the live website.

However, database changes require careful review. A database push can overwrite newer production information, depending on what is transferred. Sites that receive orders, registrations, comments, or other user submissions need a deployment procedure that protects data created after the staging copy was made.

Best for: WordPress businesses, publishers, agencies, and developers who want managed staging alongside their hosting service.

WP Engine Staging and Development Environments
WP Engine provides separate WordPress environments for production, staging, and development. Each environment operates independently, allowing developers to test updates without directly affecting the live installation.

The platform also offers sandbox sites designed for WordPress development. These provide a development environment for work that does not need to run on the production website.

This arrangement is useful for teams that maintain business websites, customer projects, or multiple WordPress installations and need a clear separation between development work and live operations.

Key features
Separate production, staging, and development environments.

Independent WordPress installations for testing.

Sandbox sites for development work.

Support for testing plugin and theme changes.

An environment management workflow within the hosting platform.

A development environment can be used for substantial changes, while staging can serve as the final testing point before a release. Keeping these roles separate can help teams identify problems earlier and reduce the number of untested changes reaching production.

The available configuration depends on the hosting plan and environment type. Website owners should confirm the restrictions that apply to their accounts before planning a deployment workflow.

Best for: WordPress agencies, professional publishers, and businesses that require separate development and pre-release testing environments.

WordPress.com Staging Sites
WordPress.com includes built-in staging functionality on its Business and Commerce plans. Website owners can create a separate copy of their production site, test changes, and synchronize selected files or database content when the work is ready.

This approach removes the need to install and maintain a separate staging plugin for the basic staging workflow.

Key features
A separate copy of the existing WordPress website.

Testing for plugin updates, themes, and redesigns.

Options to synchronize files and database content between staging and production.

Support for developer access through SFTP, SSH, and WP-CLI.

Staging sites that are kept out of search engine indexes.

The database synchronization process deserves particular attention. Replacing the production database with the staging database can overwrite newer information, including customer details and online store orders. Website owners should review the destination data before synchronizing environments.

WordPress.com is a practical option for publishers and businesses already using its managed hosting service. Its built-in staging tools can simplify testing because the environment is managed through the existing hosting dashboard.

Best for: WordPress.com Business and Commerce customers who want integrated staging without a separate staging plugin.

SiteGround Staging
SiteGround offers a WordPress staging tool through its hosting control panel. It allows eligible customers to create a separate development copy of their website, test changes, and deploy approved work to the live installation.

The feature is available on GrowBig and GoGeek hosting accounts for WordPress sites. Its availability and technical restrictions should be checked before choosing a hosting plan specifically for staging.

Key features
Creation of staging copies through Site Tools.

Testing of website updates and custom code.

Management of staging environments.

Full or selective deployment options.

Restoration options for recovering from deployment problems.

SiteGround's staging service is useful for WordPress owners who prefer a hosting-based workflow rather than manually copying website files and databases.

Before using it, check whether the website meets the service's technical requirements. SiteGround documents restrictions involving database size, database table counts, available account resources, and WordPress Multisite compatibility.

These limits matter for larger websites and installations with complex database structures.

Best for: WordPress site owners using eligible SiteGround plans who need a straightforward way to test and deploy updates.

Vercel Preview Deployments
Vercel provides preview deployments for web applications, giving developers a separate URL where they can inspect changes before releasing them to production.

The platform supports deployments through connected Git repositories, its command-line interface, deployment hooks, and its API. When a supported repository is connected, new commits and pull requests can trigger deployments automatically.

This makes Vercel particularly useful for development teams that want testing to become part of their normal coding and review process.

Key features
Automatic preview deployments for supported Git workflows.

Unique URLs for reviewing deployed changes.

Separate local, preview, and production environments.

Environment-specific variables and configuration.

Deployment logs and tools for inspecting build results.

Options to promote a deployment to production.

A developer can create a feature branch, make changes, and review the resulting deployment before merging the work into the production branch. Other team members can use the preview URL to check page layouts, application behavior, and functionality.

Vercel also supports custom environments for specialized workflows, including staging and quality assurance, on eligible plans.

However, preview deployments are not a substitute for every type of staging infrastructure. Applications that depend on databases, authentication services, third-party APIs, or background processing need suitable test configurations for those components.

Best for: Developers building web applications and websites with Git-based deployment workflows, particularly projects that benefit from automated previews and collaborative code reviews.

Netlify Deploy Previews
Netlify provides Deploy Previews that let teams review changes before publishing them to production. When a supported Git repository is connected, opening a pull request or merge request can trigger a preview deployment automatically.

Each preview receives a separate URL, allowing developers, designers, clients, and other reviewers to inspect the proposed changes.

Netlify also supports branch deployments, which provide previews associated with individual branches rather than a specific pull request.

Key features
Automated previews for supported pull request and merge request workflows.

Separate URLs for reviewing proposed changes.

Branch deployments for longer-running development work.

Deployment contexts for configuring builds and environment variables.

Collaboration features for collecting feedback.

Options for restricting access to non-production deployments.

Deploy Previews can reduce the time spent creating manual test environments for websites and applications that already use Netlify's deployment workflow.

The platform also documents an important security consideration: preview URLs can be accessible to anyone who has the link unless appropriate access controls are configured. Netlify adds a noindex header to Deploy Previews, but branch deployments do not receive the same default indexing treatment in every case.

Website owners should configure privacy and indexing controls instead of assuming every non-production URL is automatically private.

Best for: Web development teams, agencies, and businesses that use Netlify and want clients or colleagues to review changes before release.

Cloudflare Pages Preview Deployments
Cloudflare Pages offers preview deployments that allow developers to test new versions of a project without deploying those changes to production.

When a connected repository receives a supported pull request, Pages can generate a preview URL. Further commits update the preview, allowing reviewers to inspect the latest version of the proposed changes.

This approach works well for teams that use Git-based development and want to test website changes on a deployed environment rather than relying exclusively on local testing.

Key features
Preview deployments for supported pull requests.

Separate URLs for reviewing changes.

Preview aliases associated with development branches.

Access restrictions through Cloudflare Access.

Default noindex headers on preview deployments.

Integration with the Cloudflare Pages deployment workflow.

Cloudflare Access can restrict preview access to authorized users. This matters when the preview contains unreleased features, internal information, or other content that should not be available to the general public.

Cloudflare Pages is particularly relevant to projects hosted on its platform. It should not be confused with a complete replacement for a managed WordPress staging environment, because its deployment model is designed around the applications and projects supported by Pages.

Best for: Developers and teams deploying websites through Cloudflare Pages who need isolated previews and configurable access controls.

DDEV Local Development Environments
DDEV is an open-source tool for creating local web development environments. It supports PHP and Node.js projects and provides a workflow for managing development environments without requiring developers to build every component of the environment manually.

Unlike hosted preview platforms, DDEV is primarily designed for local development. Developers can use it to build websites, test application changes, and investigate problems before deploying their work to a hosting provider.

Its support for configurable, version-controlled environments makes it relevant to teams that need a repeatable development setup.

Key features
Local development environments for supported web projects.

Support for PHP and Node.js.

Configurable development environments.

Version-controlled environment configuration.

Project workflows that can be shared among developers.

Integration with Docker-based development infrastructure.

DDEV is useful when a developer needs to reproduce an application locally or test changes without publishing them to a public website. Teams can also use local environments to investigate errors before sending code to a shared staging server.

However, local testing has limitations. A website may behave differently on the production server because of differences in PHP versions, server settings, database configuration, caching, or external services. Local development should therefore be followed by staging tests when those differences could affect the release.

Best for: Developers and development teams that need repeatable local environments for supported web applications.

WordPress Studio
WordPress Studio is a free desktop application for local WordPress development. It allows developers to build and manage WordPress sites on their computers, work on customizations, and connect local development work with supported WordPress.com workflows.

It offers another route for developers who want to experiment with WordPress without immediately making changes to a public website.

Key features
Local WordPress site development.

A desktop interface for managing local sites.

Support for building and testing custom themes and plugins.

Workflows for syncing with live or staging sites.

Site previews hosted through WordPress.com.

WordPress Studio is useful for theme development, plugin testing, redesign projects, and troubleshooting. Developers can work on a local installation before transferring appropriate changes to a shared environment for final review.

Its main distinction from managed hosting staging tools is that local development happens on the developer's computer. It is not automatically a complete copy of the production hosting infrastructure, and a local installation may require additional configuration to reproduce production-specific conditions.

For businesses that need client approval or team-wide testing, local development can be combined with a hosted staging environment.

Best for: WordPress developers, designers, and site owners who want a desktop-based development workflow.

How to Choose the Right Staging or Sandbox Tool
The best tool is not necessarily the one with the largest feature list. It is the one that matches the website's platform and allows the team to test changes under conditions that resemble production.

The following considerations can help narrow the options.

Identify the website platform
Start by identifying how the website is built and hosted.

A WordPress website hosted on Kinsta or WP Engine can benefit from the staging features integrated into that hosting service. WordPress.com customers can use its built-in staging functionality on eligible plans.

A web application deployed through Vercel, Netlify, or Cloudflare Pages may benefit more from automated preview deployments tied to a Git repository.

For developers who want to work on a computer before deploying their code, DDEV or WordPress Studio may be more appropriate.

Choosing a tool that fits the existing platform can reduce the need for additional infrastructure and manual deployment work.

Check how changes reach production
Creating a staging environment is only part of the process. You also need a reliable method for moving approved changes into the live website.

Check whether the platform supports full deployments, selective file transfers, database synchronization, or promotion of an existing preview deployment.

This distinction matters because not every update should replace the entire production website.

For example, a theme adjustment might require only a code deployment. A database replacement could overwrite customer records, new orders, comments, or other information created after the staging copy was made.

Understand exactly what the deployment process will replace before approving it.

Review access controls
Staging environments can contain unpublished content, internal application features, configuration details, or copied production data.

Check whether the platform supports authentication, password protection, or access restrictions. Do not assume that a temporary URL is private simply because it is difficult to guess.

Where a staging environment contains personal information, use appropriate access controls and avoid copying sensitive production data unless it is necessary and properly protected.

Check search engine indexing
A staging site should not compete with the production website in search results.

Check the environment's indexing controls and confirm that search engines are instructed not to index the test version. Depending on the platform, this may involve HTTP response headers, access restrictions, or other configuration.

A noindex directive is useful, but it should not be treated as an access-control mechanism. It does not prevent visitors from opening a publicly accessible page.

Test the complete user journey
A page that loads correctly is not necessarily ready for production.

Test the actions visitors use to complete their tasks. Depending on the website, these may include account registration, login, contact forms, checkout, search, navigation, file uploads, and payment processing.

Check desktop and mobile layouts, review browser console errors, and inspect important integrations.

For an online store, test the checkout process using the payment provider's supported test environment. Avoid placing unnecessary real orders merely to verify that a page works.

Check backups and rollback options
Testing reduces deployment risk, but it does not eliminate it.

Create a current backup before major updates and confirm that the backup can be restored. Review the hosting provider's rollback options and establish a recovery procedure before deploying changes that could affect business operations.

A backup is useful only if the required data can be recovered when needed.

A Practical Workflow for Testing Site Updates
Regardless of which platform you choose, a consistent release process helps reduce avoidable errors.

Step 1: Create or refresh the test environment. Make sure the staging copy or local installation reflects the relevant production configuration. For database-driven websites, check whether the copied data is current enough for the planned tests.

Step 2: Apply the proposed changes. Install the plugin update, modify the theme, change the application code, or adjust the configuration in the test environment.

Step 3: Run functional tests. Check important pages, forms, navigation, authentication, and integrations. Confirm that the changes work on the devices and browsers relevant to your audience.

Step 4: Review errors and performance. Inspect application logs, browser console messages, loading behavior, and any relevant performance measurements. Check whether the update introduces new warnings or failures.

Step 5: Obtain approval. Have the responsible developer, site owner, or reviewer confirm that the changes meet the requirements. For client projects, share the preview URL or staging site with the people responsible for approval.

Step 6: Back up production and deploy. Confirm that a suitable backup exists, then deploy the approved changes using the appropriate method. Review the deployment settings carefully, particularly when database synchronization is involved.

Step 7: Verify the live website. After deployment, test the important user journeys again on the production site. Confirm that forms, navigation, checkout, and other essential functions remain operational.

Final Verdict
The right staging or sandbox tool depends on the website's platform, the team's development workflow, and the type of changes being tested.

Kinsta, WP Engine, WordPress.com, and SiteGround are relevant options for WordPress site owners who want staging integrated with their hosting arrangements. Vercel, Netlify, and Cloudflare Pages offer preview deployment workflows for supported web projects. DDEV and WordPress Studio provide local development options for testing changes before deployment.

For most website owners, the practical starting point is to use the staging or preview functionality already supported by their hosting or deployment platform. Developers with more complex requirements can combine local development, automated previews, and a dedicated staging environment.

The important consideration is not simply whether a tool can create a copy of a website. It is whether the testing process can identify problems, protect production data, control access, and support a reliable deployment.

A disciplined testing process helps website owners make updates with less risk of breaking important functions or disrupting visitors. It also gives developers and site administrators a clear process for reviewing changes before they reach the public website.

From Bug Reproduction to Playwright Test — Without Starting From Scratch

Fri, 16 Oct 2026 07:59:06 +0000

Ever reproduced a bug, documented the steps, and then had to write the same steps all over again as an automated regression test?

That repetitive workflow is what inspired me to build QA Bug, a Chrome extension designed to turn browser-based bug reproductions into Playwright test drafts.

🛠️ How it works

Reproduce the bug — Interact with the website as you normally would.

Capture the steps — Record browser actions and relevant interactions.

Add assertions — Define what the test should verify.

Generate a Playwright test draft — Turn the recorded session into a .spec.ts file that you can review, edit, and adapt to your project.

The goal isn't to replace QA engineers or magically generate perfect tests. It's to reduce repetitive work between reproducing a bug and creating a starting point for regression automation.

I'm building this as a practical tool for QA engineers and developers who want to make browser testing less repetitive.

💬 I'd like your feedback

Would you use a tool that converts bug reproduction sessions into Playwright test drafts?

What would you need before trusting the generated tests in a real project?

Which part of your bug-to-regression workflow takes the most time?

I'm interested in honest feedback from people who work with manual testing, Playwright, and test automation.

🔧 I'd rather build something QA engineers actually need than add features nobody uses.

Chrome Web Store:
https://chromewebstore.google.com/detail/qa-bug-→-regression-test/khoelciicbkdeieibchdndccdncpelbg?authuser=1&hl=tr

n8n Webhook Not Working? Test, Production, and 404 Fixes

Thu, 15 Oct 2026 15:50:00 +0000

An n8n webhook normally fails before the first workflow node runs. A 404 usually means the request did not match a registered webhook route. The common causes are a test URL with no active listener, a production URL for an unpublished workflow, the wrong HTTP method, a changed path, or an incorrect public URL on a self-hosted instance.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

Fastest check: open the Webhook node, copy the URL again, confirm whether it is Test or Production, and send the same HTTP method configured in the node. Do this before debugging credentials, expressions, or downstream nodes.

Start with the symptom

Symptom	Most likely check	First action
Test URL returns 404	No current test listener	Select Listen for test event, then resend within 120 seconds.
Production URL returns 404	Workflow is not published	Publish the workflow and copy the Production URL again.
URL works in a browser but not from the app	GET versus POST mismatch	Match the sender's method to the Webhook node.
URL has the wrong domain, port, or protocol	Self-hosted proxy configuration	Check `WEBHOOK_URL`, proxy hops, and forwarded headers.
Webhook runs but no data appears on the canvas	Production execution	Open the workflow's Executions tab.

Test URL versus Production URL

Every Webhook node exposes two URLs at the top of its panel. The official Webhook node documentation treats them as two different operating modes, not interchangeable copies of the same endpoint.

Use the Test URL while building

Select Test URL, then select Listen for test event before the external system sends its request. n8n registers the test webhook for 120 seconds and displays the incoming data in the editor. If the timer expires, register it again and resend the event.

Opening the workflow is not enough by itself. A saved test URL can return 404 later because test registration is temporary. This is useful during development because it lets one test payload appear directly on the canvas, but it is the wrong URL for a service that must call n8n at any time.

Use the Production URL after publishing

Select Production URL, copy it into the sending service, and Publish the workflow. Current n8n documentation uses Publish terminology. Publishing registers the production webhook and makes the published workflow version available to external requests until the workflow is unpublished.

Production payloads do not appear live on the editor canvas. Open Executions to confirm whether the request created a production execution and to inspect its input. No data on the canvas does not mean the webhook failed.

The n8n webhook 404 checklist

Run these checks in order. Stop as soon as the request reaches n8n.

Copy the URL from the node again. Do not rely on a URL saved in an old note, form, app, or API client.
Confirm Test or Production. Test requires a temporary listener. Production requires a published workflow.
Confirm the HTTP method. A POST request does not match a webhook registered only for GET.
Compare the path exactly. Check spelling, hyphens, route parameters, and any path changed after the sender was configured.
Check for a path-and-method conflict. n8n permits only one registered webhook for each path and method combination.
Inspect the public base URL. Do this only for self-hosted n8n behind a reverse proxy or when the node displays an internal hostname, HTTP instead of HTTPS, or the wrong port.

Check the HTTP method before the payload

The Webhook node supports GET, POST, PUT, PATCH, DELETE, and HEAD. By default it accepts one method. The sender must use that exact method. Pasting a webhook URL into a browser sends GET, so a successful browser test does not prove that a service's POST request will match, and the reverse is also true.

Current n8n versions can allow multiple HTTP methods from the node's Settings. Use that only when the endpoint genuinely needs more than one method. A tighter single-method webhook is easier to reason about and reduces accidental calls.

Check the webhook path

n8n generates a random path by default, and you can replace it with a stable custom path. Once an external app stores the URL, changing the Path field changes the route it must call. Copy the complete URL after every path change instead of editing only the last segment by hand.

n8n also requires each registered path and HTTP method combination to be unique. If another published workflow already owns the same combination, unpublish the conflicting workflow or choose a different path or method. The Webhook common-issues page documents both method matching and route conflicts.

Send a minimal request

Remove the external app from the diagnosis. Copy the exact URL from the Webhook node and test it with a safe placeholder payload. The example below uses POST. Change the method if your node uses something else.

curl --request POST 'https://n8n.example.com/webhook/example-path' \
  --header 'Content-Type: application/json' \
  --data '{"event":"webhook-test","id":"demo-001"}'

Replace the example URL with the full Test or Production URL copied from your node. For a Test URL, select Listen for test event immediately before running the command. For a Production URL, publish first. If this request works, the remaining problem is in the external app's stored URL, method, headers, authentication, or network access.

Reverse proxy and public URL problems

Skip this section on n8n Cloud. It matters when a self-hosted instance runs internally on one address but a reverse proxy exposes a different public HTTPS address.

n8n normally builds webhook URLs from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a proxy, that can produce an internal port or the wrong scheme. The official reverse-proxy configuration says to set the public URL explicitly with WEBHOOK_URL, set N8N_PROXY_HOPS to the number of reverse proxies, and pass the forwarded host, protocol, and client information from the last proxy.

WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

Do not copy this blindly. Use your real public HTTPS base URL and the actual number of proxies in the request path. Restart or redeploy n8n after changing environment variables, then copy the regenerated webhook URL from the node.

What to log before handing the webhook into production

The final Production URL location and which external system owns it. Do not paste secret query parameters into a public document.
The expected HTTP method, content type, authentication method, and a sanitized example payload.
The workflow owner and where production executions are reviewed.
The expected success response and what the sender does when it receives a non-2xx response.
The alert channel and recovery owner for failures after the webhook starts the workflow.

Once the route works, broader failures belong in the n8n workflow debugging guide. Production ownership and notifications belong in the n8n error workflow alerts guide. Keeping those jobs separate makes the webhook checklist short enough to use during an incident.

The production handoff

Test with the Test URL and one sanitized payload.
Switch the node to Production URL and copy the full value.
Publish the workflow.
Update the external service with the Production URL and matching method.
Trigger one real but safe event.
Confirm the run in Executions and record who owns failures.

n8n autosaves edits, but saved draft changes are not the same as the published version used by production executions. The save and publish documentation explains that production runs continue to use the current published version until you publish newer changes.

n8n referral

Want managed webhooks without maintaining the server?

I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Webhook still not reaching n8n?

Send the sanitized response, URL mode, HTTP method, and hosting setup. I will help narrow the failure to registration, routing, proxy configuration, or the sender.

Get help

Originally published on FloxoLab.

Mobile SEO Checklist: Test the Page Google and Customers See

Sun, 20 Sep 2026 15:50:00 +0000

Direct answer: test the exact canonical URL on a real phone and through Search Console's URL Inspection tool. Compare Google's indexed crawl with the live Google test, then confirm that the mobile page contains the complete primary content, metadata, structured data, images, and crawlable links. Complete the page's real task with touch, a small screen, and the on-screen keyboard. A responsive layout or green Lighthouse score does not prove those conditions.

Google uses the mobile version of a site's content, crawled with its smartphone agent, for indexing and ranking. There is still one search index, not a separate mobile index. The practical consequence is simple: content or links missing from the mobile result may also be missing from the evidence Google uses to understand the page.

This checklist keeps performance in its own lane. If the issue is LCP, CLS, or INP, use the separate Core Web Vitals diagnosis. Here the question is whether the mobile page is complete, accessible, navigable, and able to finish the customer's task.

Use three views of the same URL

No single test shows the whole mobile experience. Audit one representative URL through these three views, then repeat the relevant checks on each important template.

View	What it can prove	What it cannot prove alone
URL Inspection live test	Google-InspectionTool can fetch the live URL, render it, and retrieve important resources	That Googlebot received the same result, the page is indexed, ranks, or works well for every customer
Browser device mode	Responsive breakpoints, overflow, DOM content, network failures, and common device sizes	Real touch behavior, keyboard effects, weak connectivity, or every mobile browser
Physical phone	Thumb reach, tap accuracy, menus, forms, calls, payments, and the actual business task	Exactly what Googlebot rendered or which resources it could crawl

Google retired the Mobile-Friendly Test, its API, and Search Console's Mobile Usability report on December 1, 2023. Mobile usability still matters. The useful replacement is a small test stack: URL Inspection for Google's fetch and render, browser tools for implementation evidence, and a real phone for the customer journey.

1. Define the page and task before testing

Choose a page that represents a valuable template or action: a service page, product, category, booking flow, local landing page, lead form, or article. Record the exact clean URL and the task a mobile visitor should complete.

URL: https://example.com/service
Template: service detail
Primary mobile task: understand the offer and request a quote
Secondary task: call the business
Test devices: Android Chrome / iPhone Safari
Google view: URL Inspection live test
Decision: PASS / FIX / INVESTIGATE

Test the whole route, not only the first screen. A restaurant page is not successful because its hero fits the viewport if the menu cannot be opened or the order button fails. An article is not complete if its comparison table or references disappear on a phone.

2. Confirm the same indexable page reaches mobile

Responsive design normally serves the same HTML at the same URL and changes the layout with CSS. Google recommends it because it is the easiest mobile pattern to implement and maintain. Dynamic serving and separate mobile URLs can work, but they create more places for content, metadata, canonicals, redirects, and links to diverge.

For the tested URL, confirm:

the phone reaches the intended final URL instead of an irrelevant homepage or mobile error page;
the response is successful and does not depend on a device-specific redirect loop;
the robots rules, canonical, title, and meta description remain equivalent;
the page includes <meta name="viewport" content="width=device-width, initial-scale=1">;
the layout fits the viewport without routine horizontal scrolling or forced zooming;
CSS, JavaScript, images, fonts, and API responses required for the primary content are not blocked.

A desktop-only page can still be indexed if Googlebot Smartphone can access it, but that does not make it usable. Conversely, a polished mobile shell can fail indexing when it carries a different noindex, canonical, empty render, or blocked resource.

3. Compare Google's indexed crawl with the live test

Open the exact URL in Search Console and compare the indexed information with the live test. The indexed view describes Google's last processed version and reports whether it was crawled as a smartphone or desktop. The live test uses Google-InspectionTool to fetch the current page. It is useful after a fix, but it is not the same crawler as Googlebot and its pass does not mean the URL is already indexed.

After the live test completes, inspect the screenshot, rendered HTML, and loaded resources. Search the rendered HTML for the H1, a distinctive sentence from the main content, important internal links, structured data, image alt text, and the primary call to action. The screenshot is a quick visual clue, while the HTML tells you whether the information exists in the render.

Symptom	Likely cause	Next check
Blank or incomplete screenshot	Blocked assets, rendering error, delayed app shell, or server response difference	Resource list, console, server logs, rendered HTML
Main copy absent from HTML	Content requires a click, swipe, typing, or later API request	Disable interaction and reload; inspect the initial and rendered DOM
Images or styles missing	robots.txt, CDN permissions, expiring URLs, mixed content, or incorrect paths	Open each failed resource and compare the mobile request
Wrong canonical or robots rule	Mobile template, edge cache, plugin, or environment drift	Compare response headers and rendered head across devices
Navigation links absent	Menu items injected only after interaction or removed at the breakpoint	Inspect rendered anchors and the mobile navigation source

Do not lazy-load primary content only after user interaction. Google documents that its crawler does not swipe, click, or type to reveal that material. Content can sit inside an accordion for a compact layout, but the information should already be present and available to the rendered page.

4. Compare mobile and desktop content parity

Content parity does not mean identical pixels or identical DOM order. The mobile design can stack columns, collapse supporting sections, or change image crops. It does mean that the same page job and important evidence survive the layout change.

Primary content: the answer, product details, service scope, prices or qualifiers, evidence, and next step remain available.
Headings: clear and meaningful headings still describe the same sections.
Metadata: title and meta description are equivalent across served versions.
Structured data: the same relevant entities and correct URLs are present in the mobile render.
Images and video: useful media, alt text, captions, and supporting context do not disappear.
Internal links: important discovery and next-step links remain in the rendered HTML.

Use a text or DOM comparison when dynamic serving or separate mobile URLs are involved. For a responsive site, resize the page and inspect CSS rules that hide or replace blocks. A visually hidden duplicate can also create confusion, so the goal is one complete, coherent mobile page, not two overlapping copies.

Open the menu with touch, follow each important route, use the browser Back button, and repeat with the phone rotated. The menu control should have a clear accessible name, visible focus, a correct expanded state, and a close path that does not trap the user.

Important destinations should use normal crawlable links such as <a href="https://floxolab.com/services">. A styled <div>, a click handler without a resolvable URL, or a desktop link removed from mobile navigation can make a page harder for customers and crawlers to find. Google says limiting the links in a separate mobile version can slow discovery because it indexes the mobile version.

Check the page beyond the global menu:

breadcrumbs or back paths remain understandable;
cards have a clear destination and do not require hover to reveal it;
pagination and load-more states expose crawlable page URLs where discovery matters;
sticky headers do not cover anchored headings or the first form field;
phone, email, map, and download actions open the expected handler.

6. Check tap targets, zoom, and overlays

Use a thumb, not a mouse cursor. Test menu icons, close buttons, filters, accordions, pagination, checkboxes, and calls to action near the screen edge. Look for accidental taps, controls that overlap, and actions that appear only after hover.

WCAG 2.2 Level AA sets a 24 by 24 CSS pixel minimum for pointer targets, with documented exceptions including sufficient spacing and inline text links. Its enhanced Level AAA target is 44 by 44 CSS pixels. Google's web.dev guidance recommends aiming around 48 device-independent pixels with space between touch controls. For frequent or consequential actions, the larger practical target is the better design goal.

Do not disable user zoom. A layout that only works by preventing pinch zoom hides an accessibility problem instead of solving it. Let the viewport fit naturally and let users enlarge content when they need to.

Dismiss every banner, consent dialog, chat launcher, and promotion at the tested breakpoint. A close icon must be reachable and remain visible when the on-screen keyboard opens. Google recommends banners that occupy a small portion of the screen instead of promotional interstitials that obscure the primary content.

7. Complete the form and business action

A mobile SEO check is incomplete until the page does the thing it promises. Submit a test lead, book a test appointment, add a product, start checkout, call the number, open directions, or download the file. Confirm the result arrives in the real destination without duplicate submissions.

For forms, verify:

every input has a persistent visible label and a useful error message;
email, telephone, number, date, and address fields invoke sensible mobile keyboards or pickers;
autofill and password managers do not overwrite unrelated fields;
validation does not clear correct values or jump to an invisible error;
the keyboard does not cover the active field, submit button, or error summary;
success is visible and the lead, booking, order, or message arrives once;
the action still works with a slow connection or a brief retry.

Record operational failures separately from indexation failures. A form can be fully crawlable and still lose every mobile lead. That makes it a critical business defect even when no SEO tool raises a warning.

8. Check responsive media and layout boundaries

Inspect the page at a narrow phone width, a larger phone, and at least one intermediate width. Breakpoints often fail between the devices a designer chose for screenshots.

text reflows without a fixed-width container pushing the page sideways;
tables wrap, scroll inside a labelled container, or transform without losing relationships;
images use an appropriate source for the viewport and retain meaningful crops;
video, maps, embeds, code blocks, and long URLs stay within the content column;
image width and height reserve the correct aspect ratio;
important text is real HTML, not trapped only inside an image.

These checks overlap with delivery, but this guide does not grade loading performance. If large media or scripts cause slow loading, layout shift, or poor interaction responsiveness, move that evidence into the performance workflow and validate the mobile task again after the fix.

9. Test more than one phone context

One device cannot represent the whole audience. Use analytics or business evidence to choose a small matrix, then include the riskiest context instead of chasing every model.

Context	Why it matters	Practical test
Small viewport	Exposes overflow, cramped controls, and sticky-overlay conflicts	Older or compact phone width
iOS and Android	Browsers, keyboards, date controls, and safe areas differ	Safari on iPhone and Chrome on Android
Slow or unstable network	Late assets and retries can break the task	Browser throttling plus one real cellular test
Text zoom or larger system text	Reveals clipped labels and fixed-height controls	Increase text size and repeat navigation and form tasks
Signed out or fresh session	Consent, location, login, and first-visit overlays change the page	Private window or cleared test profile

Prioritize representative templates and conversion routes. A page-level SEO audit can supply the intended query and page job; this mobile checklist then verifies that the same job survives the smaller screen and smartphone crawl.

What not to do

Do not use a Lighthouse score as the mobile audit result. It is useful evidence, not a content-parity, crawl, navigation, or conversion test.
Do not remove useful content just to shorten the mobile page. Reorganize it with clear sections or accordions while keeping it available.
Do not require a click, swipe, or search to load primary indexable content. Googlebot will not perform those interactions.
Do not block CSS, JavaScript, images, or API resources that Google needs to render the page.
Do not hide navigation behind non-links. Important routes need resolvable <a href> destinations.
Do not rely only on device emulation. It does not reproduce a real finger, keyboard, browser chrome, app handoff, or unreliable connection.
Do not cover the first screen with a promotional interstitial. Use a compact, dismissible banner when the message is necessary.
Do not change URLs during a responsive redesign without a real need. If a move is required, use the site migration SEO checklist.

Final mobile SEO validation record

Finish with observed evidence and an owner:

Canonical URL and response: PASS / FIX / INVESTIGATE
Indexed mobile render and live Google test: PASS / FIX / INVESTIGATE
Primary content parity: PASS / FIX / INVESTIGATE
Metadata and structured data: PASS / FIX / INVESTIGATE
Navigation and crawlable links: PASS / FIX / INVESTIGATE
Tap targets and overlays: PASS / FIX / INVESTIGATE
Form or business task: PASS / FIX / INVESTIGATE
Responsive media and overflow: PASS / FIX / INVESTIGATE

Highest-impact defect:
Evidence and reproduction steps:
Template or page owner:
Release date:
Post-release test:

Re-run the failed task after deployment on the public URL. Then use URL Inspection's live test to confirm the final Google render. For a redesign or platform move, include this record in the broader pre-launch and post-launch comparison so mobile parity does not disappear between environments.

Sources checked

Mobile indexing, rendering, responsive design, link, interstitial, and touch-target guidance was verified from Google, Chrome, web.dev, and W3C documentation on August 4, 2026.

<a href="https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing" targ

n8n Free Trial: 3 Workflows to Test in 14 Days

Thu, 10 Sep 2026 15:50:00 +0000

Direct answer: use the 14-day n8n Cloud trial to prove three narrow jobs, not to build a giant automation system. Keep Cloud only if at least two workflows run reliably, a named person can diagnose a failure, and the expected production executions fit the paid plan. Cancel if native tools already solve the jobs or the workflows still need constant rescue on day 14.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

This guide is a trial experiment for small-business owners and operators. It is not a broad introduction to n8n, a Cloud versus self-hosted comparison, or a complete pricing table. The job here is to leave the trial with evidence: three test records, three failure drills, an execution estimate, and a clear keep-or-cancel decision.

Know the trial limits before day one

Current trial fact	What it means for your test
14 days	Prepare sample data and app access before signup so the clock is used for testing.
No credit card required for the Starter and Pro Cloud trial	The trial ends unless you manually subscribe. There is no ongoing free n8n Cloud plan.
Pro features under Starter compute limits	You can evaluate features such as execution search and workflow history, but not Pro-level compute capacity.
800 AI Assistant credits during the trial	Use the preview for one controlled build. Do not make AI credits the reason the core workflows pass.
Manual executions do not use the production quota	Develop and test manually first. Activate schedules and webhooks only when acceptance checks are ready.

Official-source mismatch, checked August 8, 2026: the current n8n pricing FAQ says the trial uses Starter's 2,500-execution limit, while the dedicated free-trial documentation still says 1,000 executions. Treat the quota shown inside your workspace as binding. Until it confirms otherwise, plan as if you have 1,000 production executions.

Trial and plan details can change. The current pricing page also lists 320 MiB RAM and 10 millicores of burstable CPU for trial and Starter compute. That is enough for small tests, but large files, long code steps, and memory-heavy AI work can distort the result. Use small, representative records first.

A useful trial begins with a small test pack. Create five dummy leads, one week of sample sales or booking rows, and six fake invoices with different due dates and statuses. Use test inboxes and test chat channels. Do not start with live customer records, automatic payment actions, or messages that can reach real customers.

Name one owner. This person builds the workflow, records failures, and decides whether it passed.
Write the expected output. For every sample record, state what should happen and what must not happen.
Check the native route. If your form, accounting tool, or CRM already provides the needed alert or reminder, test that first.
Prepare credentials. Know which test accounts need access, but add credentials through n8n's credential cards. Never paste secrets into a prompt.
Create a result sheet. Record workflow, input, expected result, actual result, execution count, failure, recovery time, and decision.

A practical 14-day schedule

Days	Work	Evidence to keep
Before signup	Prepare dummy data, test accounts, acceptance checks, and the result sheet.	Test pack is ready before the clock starts.
1-2	Set the workspace timezone, connect test credentials, and run one manual trigger.	Correct timestamps and one clean credential test.
3-5	Build and break the lead alert.	Valid, invalid, and duplicate lead results.
6-8	Build and break the weekly summary.	Correct totals, empty-data handling, and delivery proof.
9-11	Build and break the invoice reminder.	Due, paid, disputed, and duplicate invoice results.
12	Run credential, timeout, duplicate, and missing-data failure drills.	Recovery steps and time to diagnose each failure.
13	Estimate monthly production executions and name the support owner.	Normal-month and busy-month estimates.
14	Use the scorecard, export workflows, and keep or cancel.	A written decision, not a vague intention to revisit later.

Workflow one: route a qualified lead alert

Start with a form or webhook, normalize the fields, reject records missing an email or phone number, and send a notification to the person who owns follow-up. Use email, Slack, Telegram, Google Chat, or another channel your team already checks. The workflow is valuable when it filters and routes leads, not merely when it copies every form submission into another inbox.

Minimum path: Form or Webhook → Edit Fields → If → destination app.

Send three valid leads with different service interests. Each should reach the correct owner with a timestamp and source.
Send a lead with no usable contact detail. It should enter a review route, not disappear or trigger normal follow-up.
Send the same lead twice. The owner should not receive two identical alerts if duplicates are realistic in your process.
Disable or invalidate the destination credential. Confirm that the failure is visible and that the owner knows how to retry safely.

Pass: five valid test leads reach the right owner within the expected time, invalid records are held for review, and a duplicate does not create duplicate work. Fail: the team still checks the form manually because it does not trust the alert.

Workflow two: deliver a weekly operating summary

Use a Schedule Trigger to read a small sheet, table, or database and calculate three numbers that affect a real decision. A bakery might track orders, average order value, and unfulfilled pickups. A clinic might track new inquiries, booked appointments, and unanswered leads. Compute the numbers deterministically before asking AI to explain them.

Minimum path: Schedule Trigger → source app → filter or aggregate → email or chat.

Run the workflow manually against a known sample and compare every total with a hand calculation.
Test an empty week. The summary should say there is no data, not invent a trend or fail silently.
Test one malformed row and one late record. Decide whether to exclude, flag, or stop.
Activate the schedule once and verify the workspace timezone, delivery time, and production execution record.

Pass: the owner receives the correct numbers at the correct time and can trace them to source rows. Fail: the summary is polished but the totals cannot be reproduced.

Workflow three: create a safe invoice reminder

First check the native reminder feature in your accounting platform. Use n8n when the job needs data from more than one system, different rules by customer or invoice, an internal approval, escalation to an account owner, or a stop condition that the native feature cannot express.

During the trial, create an internal task or a draft reminder instead of sending directly to a customer. Use fake invoices with statuses such as due soon, overdue, paid, disputed, and missing an email address. Only consider automatic external sending after someone has approved the wording, timing, opt-out handling, and stop rules.

Minimum path: Schedule Trigger → invoice source → due-date and status checks → draft or internal approval.

A due invoice creates one draft with the correct customer, amount, invoice number, and due date.
A paid or disputed invoice creates no reminder.
A missing email creates an internal review task instead of an invalid send attempt.
Running the workflow twice does not create two reminders for the same invoice and stage.

Pass: the workflow applies status and duplicate safeguards before any customer-facing action. Fail: a changed invoice status can still produce an incorrect or repeated reminder.

Use the new AI Assistant for one controlled build

n8n's current AI Assistant is a Cloud-only preview that can create, edit, test, and troubleshoot workflows inside the editor. It replaces the older assistant experience as the actively developed path. Preview features can change and can produce incorrect workflows, so use it to accelerate one draft, then inspect every node and test the result yourself.

Example prompt: Create a test workflow that receives a lead by webhook, requires either email or phone, routes valid records to my test Slack channel, sends invalid records to a review branch, and records the result. Use dummy data. Ask before activating the workflow or changing credentials.

Add credentials through the credential card when asked. Do not paste API keys, passwords, or live customer data into the chat. n8n says the assistant asks for confirmation before high-impact actions, but the operator still owns permissions, message content, data exposure, and the final activation. Trial credits are token-based, so long conversations and large workflows consume more than a short, focused request.

Understand what consumes an execution

n8n counts a complete production workflow run as one execution, regardless of how many steps it contains. Manual runs from the editor do not count. Triggered production runs do count, including failed scheduled runs. Polling triggers count when they find new data, and each webhook request normally starts an execution. Sub-workflows and error workflows do not add separate billable executions.

Frequency changes the economics quickly. A daily summary is about 30 executions per month. A five-minute schedule is roughly 8,640 to 8,928 scheduled runs in a 30- or 31-day month, even before other workflows and retries. Use event triggers when appropriate, avoid pointless polling, and estimate both a normal month and a busy month before choosing a plan.

Run failure drills before you trust the workflows

A successful happy-path demo only proves that one sample worked once. On day 12, break each workflow deliberately and record what the operator sees, whether partial actions can repeat, and how long recovery takes.

Remove one required field and send an empty source.
Expire or disconnect one test credential.
Submit the same record twice.
Simulate an app timeout or rate-limit response.
Change an invoice from overdue to paid after it enters the queue.
Run a scheduled workflow across the wrong timezone boundary.

A useful workflow exposes the failure, avoids unsafe partial repeats, and gives the owner a clear retry path. If the same error can send a second customer message, charge twice, or overwrite good data, the workflow is not ready for production.

Use this keep-or-cancel scorecard

Question	Keep signal	Cancel or redesign signal
Did at least two workflows solve a real job?	The owner stopped a repeatable manual check or handoff.	The workflows were demos with no process owner.
Were results reliable?	Acceptance checks and failure drills passed.	The team still verifies every result manually.
Can someone support it?	A named owner can find executions, diagnose failures, and retry safely.	Only the original builder understands the workflow.
Does the usage fit?	Busy-month executions leave reasonable headroom.	Polling, retries, or volume already exceed the likely plan.
Is n8n the simplest route?	Filtering, transformation, routing, approval, or error handling justifies it.	A native feature solves the job with less maintenance.

Keep Cloud when at least two workflows pass, the support owner is clear, and the paid-plan cost is smaller than the time and errors removed. Cancel when native tools win, the workflows remain fragile, or no one will own them. A cancelled trial that prevents a poor automation purchase is still a successful test.

Export before the trial ends

There is no permanent free n8n Cloud plan. If you do not subscribe, the trial expires. n8n's current Cloud documentation says the workspace owner can download workflows from a recent backup for 90 days after the trial, after which the data is permanently deleted. Export your workflow JSON files and result sheet on day 14 instead of relying on that recovery window.

If the trial passes, activate only the workflows whose safeguards are complete. Start with one production workflow, monitor its executions, and add the next one after the owner has handled a real failure. The point is not to automate everything. It is to prove that one small system can save time without creating a larger support problem.

Sources checked

Product limits and feature behavior were verified on August 8, 2026. n8n can change trial terms, pricing, preview features, and plan limits.

n8n partner link

Test one useful workflow before you automate m

Apollo Free Trial: What You Can Test Before Paying

Sat, 05 Sep 2026 15:50:00 +0000

Direct answer: create an Apollo Free account first and do not activate the one-time 14-day paid-plan trial until your test segment is ready. Use Free to define the market and filters. During the trial, inspect 25 companies, verify 10 contacts, reveal only the data you need, test one sequence with your own inbox, and measure credit use. Upgrade only if the sample is good enough and a paid feature removes a real constraint. Otherwise, let the workspace return to Free.

Partner disclosure. This guide includes a partner link to Apollo. If you create an account or purchase through it, I may earn a commission at no extra cost to you.

This guide has one narrow job: evaluate Apollo before paying. It does not replace the B2B prospect list guide, which covers ICP, company filters, buyer roles, and exclusions. If you have not chosen the research system yet, use the Apollo vs LinkedIn Sales Navigator comparison first. Use the separate Apollo pricing guide for the current plan table, credit costs, add-ons, and small-team scenarios. Here, the outcome is a written pass, upgrade, or revert decision based on one representative segment.

Apollo Free account and free trial are not the same thing

Current fact	What it means for your test
Free account	A persistent $0 workspace for preparing filters and trying limited prospecting tools. You can keep it after the trial.
Paid-plan trial	An eligible Free account can start one 14-day trial of Basic or Professional. Custom plans do not have a self-serve trial.
No credit card required	You can evaluate the trial without entering a card. At the end, upgrade or return to Free.
Trial credit allowance	Apollo's public pricing FAQ currently says 50 credits plus 5 mobile credits. Check the confirmation screen because Apollo is rolling out a new credit system.
Bulk action limit	You can select up to 25 records at once for a bulk save or action during the trial.
Phone and calling limits	The trial documentation lists up to 20 phone-number accesses, 60 total calling minutes, and 10 minutes per call.

Checked in a live Free workspace on August 11, 2026: the account showed a $0 Free plan, 75 monthly credits, two sequences, and five AI Assistant chats. The same workspace had already used its Professional trial. Your allowance can differ during Apollo's credit-system rollout, so the numbers inside your own Billing screen are binding.

If you upgrade during the trial, Apollo says the trial ends immediately and unused trial days or credits do not carry over. You can switch between Basic and Professional during the original 14-day window, but the clock does not reset. Do the useful testing before you buy.

Prepare a small test pack before starting the clock

The trial becomes valuable when you know what a good result looks like. Pick one market, one offer, and one buying role. A broad search across several industries will make the database look busy, but it will not tell you whether Apollo can support your actual outreach process.

Write the segment. Define geography, industry, company size, buyer role, and at least three exclusions.
Choose 25 companies. This fits the trial's bulk-selection ceiling and is large enough to expose weak filters.
Choose 10 contacts. Verify their current role and company manually before spending more credits.
Name required fields. Decide whether you truly need work email, phone, LinkedIn URL, company website, headcount, or technology data.
Set pass criteria. For example, require at least 20 of 25 companies to fit and 8 of 10 sampled contacts to hold the expected role. These are evaluation thresholds, not Apollo accuracy claims.
Prepare one safe message. Use your own or a controlled test inbox first. Do not make live cold sends the first sequence test.

A practical 14-day Apollo trial schedule

Days	Test	Evidence to keep
Before trial	Build the segment, exclusions, sample sheet, and pass criteria on Free.	One ready 25-company test pack.
1-2	Rebuild the search and test filters that matter to your market.	Saved search plus notes on false positives and missing companies.
3-5	Inspect 25 companies and 10 contacts against public company pages and professional profiles.	Fit, role, stale-data, and uncertain-data labels.
6-7	Reveal only the email or phone data needed for the sample and review credit history.	Credits before and after each action.
8-10	Build one sequence and send it only to a test inbox or controlled recipient.	Merge fields, timing, stop rules, unsubscribe path, and reply behavior.
11-12	Test AI Assistant or the dialer only if either feature affects the buying decision.	Time saved, credit use, errors, and required manual review.
13-14	Score the result, document the required plan, and upgrade or revert.	A written decision with no unused trial work left behind.

Test one: can Apollo isolate the right market?

Start with company filters, then add people filters. Review the first 25 companies one by one. A company passes only when it matches the real market, not merely because Apollo assigned a nearby industry label. Record why every false positive entered the list, then tighten one filter at a time.

Confirm the company still operates, serves the target geography, and fits the intended size range.
Check whether subsidiaries, agencies, recruiters, consultants, or competitors should be excluded.
Review job titles for function and seniority. Similar titles can represent very different buying authority.
Save the clean search only after the sample meets the written company-fit threshold.

Pass: the search repeatedly produces companies and roles that a human reviewer would accept. Fail: the apparent list size collapses after manual checks or depends on exclusions you cannot express consistently.

Test two: measure contact quality and credit use together

Apollo's terms explicitly say its data may contain errors, duplicates, and omissions. Treat a reveal as a candidate record, not a guarantee. For 10 contacts, verify current employer and role from a public company page or professional profile. Mark records as confirmed, stale, conflicting, or uncertain.

Before revealing anything, open Settings > Billing > Credit usage & AI > History. Record the starting balance, reveal the smallest useful sample, then inspect the history again. Apollo's current system can charge different actions for email, phone, enrichment, connected calls, AI research, exports, and other features. The confirmation shown before an action and the resulting history are more reliable than an old blog post or remembered price table.

Do not spend the trial proving volume. Ten carefully checked contacts reveal more about fit than hundreds of unreviewed records. Spend mobile credits only when phone data is part of the real workflow.

Test three: build one sequence without risking your domain

Create one short sequence for the chosen segment. Add a few controlled records that you own, review every merge field, and send to a test inbox. You are evaluating the workflow, not trying to prove that a 14-day blast can generate revenue.

Check the sender name, reply-to address, timezone, daily schedule, and delay between steps.
Preview records with missing company names, first names, or custom fields.
Confirm what happens after a reply, bounce, unsubscribe, manual removal, or booked meeting.
Keep the first live volume low and monitor the sending mailbox outside Apollo as well.
Verify any mailbox-provider restriction shown in your workspace before connecting an important domain.

Apollo can organize sequencing, but it cannot guarantee inbox placement, replies, meetings, or revenue. Your list quality, sender reputation, message relevance, consent basis, and local marketing rules still matter. Apollo's terms place responsibility for lawful use and verification on the customer.

Test AI Assistant only when it saves a real step

Apollo's current documentation gives Free accounts five AI Assistant chats per billing cycle and up to 10 messages in each chat. Paid access currently offers more generous use. Chatting does not automatically consume credits, and Apollo asks for confirmation before a credit-consuming action. Still, verify every output and avoid entering sensitive information.

A useful test is narrow: ask the assistant to create or refine the saved search for your written segment, then compare the result with your manual filter setup. Record whether it saved time and whether you had to correct industries, titles, exclusions, or geography. Do not upgrade because the assistant produced fluent text. Upgrade only if it reduces repeatable research work without weakening control.

If calling matters, verify dialer access before choosing a trial

Apollo's dedicated trial help page says the dialer is available only in the Professional trial. The current in-account Basic plan card we checked listed a US dialer. Because these official surfaces conflict, do not assume either is universal. Review the exact trial confirmation screen or ask Apollo support before activation if calling is part of the purchase decision.

If dialer access appears, test it with your own or an explicitly consenting recipient first. Confirm number setup, recording settings, call outcome logging, and credit use. The trial documentation lists 60 total minutes and a 10-minute limit per call, which is enough for workflow evaluation but not a calling campaign.

What the Apollo trial cannot prove

That every email, phone number, company attribute, or job title is current and accurate.
That messages will reach the inbox or that a mailbox will preserve its sender reputation.
That a segment will produce replies, meetings, pipeline, or revenue at scale.
That having access to contact data gives you permission to use it in every jurisdiction.
That the credit allowance or feature limits in your trial will remain unchanged later.

The trial can prove something narrower and still valuable: whether Apollo finds enough plausible records for one market, whether your team can verify and organize them efficiently, whether the credit economics are visible, and whether the paid workflow is meaningfully better than staying on Free.

Choose Basic or Professional by the feature you must prove

Start with Basic when the decision is mainly about search, saved lists, enrichment, and simple sequences. Choose Professional only when a Professional-level workflow is genuinely part of the buying decision, such as advanced sequencing, reporting, team controls, or the dialer access confirmed for your workspace. Do not select the larger trial merely to explore more menus.

Avoid activating either trial until you can name the decisive feature in one sentence. If the Free account already supports the recurring work and the paid feature does not save enough time or improve control, returning to Free is the correct outcome.

Use this upgrade-or-revert scorecard

Question	Upgrade signal	Revert signal
Did targeting pass?	The 25-company sample met the written fit threshold.	Manual review removed too much of the list.
Was contact data useful?	The verified sample supported the intended channel.	Too many records were stale, conflicting, or missing.
Were credits predictable?	The team can estimate monthly use from actual history.	Required actions consume credits too quickly or unclearly.
Did the sequence work safely?	Fields, timing, replies, and stop rules behaved as expected.	The process still needs constant manual correction.
Did a paid feature matter?	It removed a measured bottleneck in the real process.	The Free account already covers the useful work.

What not to do during the trial

Do not activate before the segment, sample, and acceptance criteria are ready.
Do not reveal every available field when the workflow only needs one channel.
Do not treat database access as proof of accuracy or legal permission.
Do not test deliverability by sending a large cold campaign from a valuable domain.
Do not upgrade early. Apollo says that immediately ends the trial.
Do not judge Apollo by record count alone. Judge the verified fit and usable workflow.

Sources checked

Trial rules, credit behavior, AI limits, sequence controls, and legal boundaries were checked on August 11, 2026. Apollo can change plans, allowances, and product behavior.

Apollo partner link

Test one qualified segment

Go 1.26.2 Released: Security Fixes, Regression Patches, and an Upgrade Playbook

Mon, 13 Apr 2026 10:30:26 +0000

Go 1.26.2 Released: Security Fixes, Regression Patches, and an Upgrade Playbook

Go 1.26.2 was released on 2026-04-07 as a patch release focused on security and stability.

If you are running Go 1.26.x in production, this is the kind of release you should evaluate quickly.

Go 1.26.2 includes security fixes to the go command, compiler, and the archive/tar, crypto/tls, crypto/x509, html/template, and os packages, plus bug fixes across the go command, go fix, compiler, linker, runtime, net, net/http, and net/url.

TL;DR (beginner + technical)

If you are on 1.26.0 or 1.26.1, plan an upgrade to 1.26.2.
If your service is internet-facing, treat this as high priority because security-sensitive packages were patched.
Verify checksums before installation.
Roll out with canary + SLO guardrails, not a full one-shot deployment.

If you are new: what does "1.26.2" mean?

Go versions follow a major.minor.patch pattern:

1 = major line
26 = minor release line
2 = patch release

Patch releases are usually about fixing behavior, not adding new language features.

Why this patch matters technically

Go 1.26 introduced important runtime and toolchain changes. Point releases like 1.26.2 are where real-world regressions and security backports get addressed.

Use this release as both a security update and a reliability update.

Area	Patch focus in 1.26.2	Practical risk if delayed
`crypto/tls`, `crypto/x509`	Security hardening and correctness fixes	TLS/cert path issues at trust boundaries
`html/template`	Security-related fixes	Potential template safety exposure
`cmd/go`, `go fix`	Toolchain reliability fixes	Slow/hanging CI or broken automation flows
Compiler/linker/runtime	Regression and crash fixes	Build or runtime instability in production
`net`, `net/http`, `net/url`	Networking correctness fixes	Subtle request/routing/parsing behavior regressions

Deep look at the Go1.26.2 milestone

Using the public GitHub milestone API for Go1.26.2:

Milestone state: closed
Open issues: 0
Closed issues: 31

What the issue distribution tells us

From a title/label scan of closed issues, the cluster is practical and production-facing:

CVE-related titles: 10
Security backport-labeled titles: 8
Compiler/runtime-labeled items: 10
cmd/go-labeled items: 1
Testing-labeled items: 2
Documentation/backport consistency items: 4

This is the normal fingerprint of a mature patch release: security + high-impact regressions + release-quality cleanup.

Security and CVE signal

The milestone shows clear CVE and security backport activity, including:

#78428 security: fix CVE-2026-32283 [1.26 backport]
#78426 security: fix CVE-2026-32282 [1.26 backport]
#78424 security: fix CVE-2026-27144 [1.26 backport]
#78422 security: fix CVE-2026-27140 [1.26 backport]
#78362 crypto/x509 ... (CVE-2026-32280)
#78360 crypto/x509 ... (CVE-2026-32281)

Even without changing your app code, patching core trust-boundary packages (tls, x509, templates, and toolchain) reduces real production risk.

Regression fixes you may actually notice

Representative examples from the milestone:

#78058: cmd/go cache trim could block for 20+ minutes on macOS.
#78111: net/url parsing regression affecting MongoDB multi-host connection strings.
#78041: runtime crash on Windows in 1.26.0/1.26.1.
#78239: linker panic on darwin/arm64.
#78191: cmd/fix panic in edge cases.

Beginner translation: these are exactly the kinds of bugs that become random CI failures, odd runtime crashes, or flaky production behavior.

Download artifacts and checksum verification

Official download page: go.dev/dl

Selected Go 1.26.2 artifacts from the official download feed:

Artifact	Platform	Size	SHA256
`go1.26.2.src.tar.gz`	Source	33 MB	`2e91ebb6947a96e9436fb2b3926a8802efe63a6d375dffec4f82aa9dbd6fd43b`
`go1.26.2.linux-amd64.tar.gz`	Linux x86-64	64 MB	`990e6b4bbba816dc3ee129eaeaf4b42f17c2800b88a2166c265ac1a200262282`
`go1.26.2.darwin-arm64.pkg`	macOS Apple Silicon	63 MB	`5daa0b7ba59f703c5b6be2bd48437062224fd9244160e8e73a1c9f7eb8a11784`
`go1.26.2.darwin-amd64.pkg`	macOS Intel	66 MB	`5eab5ad8943e7666554fddd72ecbcbe64cf8f04197d6e06486fbb395b779fd8d`
`go1.26.2.windows-amd64.msi`	Windows x86-64	59 MB	`84826eca833548bb2beabe7429052eaaec18faa902fde723898d906b42e59a73`

Why checksum verification matters: it confirms the artifact you downloaded is exactly what Go published.

Example verification (macOS/Linux shell):

curl -LO https://go.dev/dl/go1.26.2.linux-amd64.tar.gz
shasum -a 256 go1.26.2.linux-amd64.tar.gz
# expected: 990e6b4bbba816dc3ee129eaeaf4b42f17c2800b88a2166c265ac1a200262282

Production-safe upgrade playbook

If your team has no formal release process yet, just follow the steps in order and keep a rollback version ready.

Use Go 1.26.2 explicitly in CI images, local dev environments, and build containers. Avoid implicit latest tags.

```dockerfile
FROM golang:1.26.2-alpine
```


Validate what your runner is actually using before tests.

```bash
go version
go env GOTOOLCHAIN GOOS GOARCH
```


Start with your existing suite, then add race detection for services that handle concurrency heavily.

```bash
go test ./...
go test ./... -race
go vet ./...
```


Execute `govulncheck` and compare findings against your previous baseline.

```bash
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...
```


Add focused tests for URL parsing, HTTP handling, TLS handshakes, and cert verification in critical flows.


Canary first, then staged rollout with explicit SLO gates (error rate, latency, crash loops, build stability).


Preserve the previous working toolchain image/tag so rollback is a fast switch, not a rebuild.

Copy-paste CI gate (practical baseline)

set -euo pipefail

go version
go env GOTOOLCHAIN GOOS GOARCH

go test ./...
go test ./... -race
go vet ./...

govulncheck ./...

Should you upgrade now?

Upgrade now (high priority): internet-facing services, heavy TLS/cert usage, or strict security posture.
Upgrade soon (scheduled): internal services on 1.26.0/1.26.1.
Plan migration path: older major line users that need broader compatibility testing.

The canonical summary of packages touched in 1.26.2.

Understand what 1.26 introduced so you can interpret which 1.26.2 fixes are stabilization backports.

Official binaries, source tarball, and checksums for every platform.

Closed issue set showing exactly what was backported into the patch.

Guidance on govulncheck, vulnerability database, and release security policy.

Data provenance

This article and its visuals are based on:

Official Go release notes and release history.
Official Go download index and checksums.
Public GitHub milestone API data for Go1.26.2.

The embedded images in this post are custom summary visuals created from those public sources.

Laravel Testing Environment Setup

Sun, 29 Mar 2026 14:36:21 +0000

title: Laravel Testing Environment Setup
published: true
description:
tags: #test #laravel #phpunit

published_at: 2026-03-26 14:38 +0000

This guide explains how to properly configure a testing environment in Laravel using .env.testing and phpunit.xml.

Overview

When running automated tests, you should isolate your testing environment from development and production. This prevents accidental data loss and improves test reliability.

⚙️ 1. Create .env.testing

Create a .env.testing file in the root of your Laravel project:

APP_NAME=laravel
APP_ENV=local
APP_KEY= # application key
APP_DEBUG=true
APP_URL=http://laravel.test

APP_LOCALE=en
APP_FALLBACK_LOCALE=en
APP_FAKER_LOCALE=en_US

APP_MAINTENANCE_DRIVER=file

BCRYPT_ROUNDS=12

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE= # your testing database (e.g., laravel-testing)
DB_USERNAME=root
DB_PASSWORD=

SESSION_DRIVER=database
SESSION_LIFETIME=120
SESSION_ENCRYPT=true
SESSION_PATH=/
SESSION_DOMAIN=null

✅ Notes
Use a separate database for testing.
Never reuse your development or production database.

Configure phpunit.xml

Update your phpunit.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
>
    <testsuites>
        <testsuite name="Unit">
            <directory>tests/Unit</directory>
        </testsuite>
        <testsuite name="Feature">
            <directory>tests/Feature</directory>
        </testsuite>
    </testsuites>

    <source>
        <include>
            <directory>app</directory>
        </include>
    </source>

    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="APP_MAINTENANCE_DRIVER" value="file"/>
        <env name="BCRYPT_ROUNDS" value="4"/>

        <env name="BROADCAST_CONNECTION" value="null"/>
        <env name="CACHE_STORE" value="array"/>
        <env name="DB_CONNECTION" value="mysql"/>
        <!-- <env name="DB_DATABASE" value="your-testing-db"/> -->
        <env name="DB_URL" value=""/>

        <env name="MAIL_MAILER" value="array"/>
        <env name="QUEUE_CONNECTION" value="sync"/>
        <env name="SESSION_DRIVER" value="array"/>

        <env name="PULSE_ENABLED" value="false"/>
        <env name="TELESCOPE_ENABLED" value="false"/>
        <env name="NIGHTWATCH_ENABLED" value="false"/>
    </php>
</phpunit>

Run Tests

Before running tests:

Ensure your testing database exists
Run migrations if needed

Then execute:

php artisan test

⚡ Tips
Isolation: APP_ENV=testing ensures .env.testing is used.
Performance:
CACHE_STORE=array
SESSION_DRIVER=array
QUEUE_CONNECTION=sync
Faster Hashing:
Reduce BCRYPT_ROUNDS during testing
Disable Extras:
Disable tools like Telescope, Pulse, etc., to speed up tests

✅ Summary

With this setup:

Tests run faster ⚡
Data remains safe
Environment stays isolated

Stop Building "Zombie UI" The Resilient UX Checklist (Playwright + Python)

Wed, 24 Dec 2025 21:50:50 +0000

The Problem: The "Zombie UI"

You click "Submit". The database is writing data. The API is processing the request perfectly. The backend is healthy. But on the screen... nothing happens.

The button still looks clickable. The cursor is still a pointer. This is the "Dead Zone" — the gap between the user's input and the interface's reaction.

According to Jakob Nielsen's Response Time Limits, you have a strict budget:

0 - 100ms: Instant. Feels like manipulating a physical object.
100 - 300ms: Slight delay. Acceptable, but noticeable.
300 - 1000ms: User loses focus. "Is it working? Did I miss the button?"
> 1000ms: Zombie Mode. The user thinks the app crashed. They will refresh the page or rage-click the button, triggering duplicate transactions.

A working backend is not enough. If your UI freezes for 2 seconds without feedback, your feature is broken.

The Solution: The 3-Step Feedback Loop

We are used to writing tests like this: expect(success_message).to_be_visible(). But that is not enough. We must assert the intermediate states.

✅ I use this Resilient UX Checklist for every async action:
The Checklist

Immediate (<100ms): The button MUST become disabled. This prevents Rage Clicks and double-charges.
Short Wait (300ms): A spinner or skeleton loader MUST appear.
Long Wait (>3000ms): If the network is terrible (e.g., subway tunnel), show a "This is taking longer than usual..." toast. Never leave the user staring at an infinite spinner.

The Code (Python + Playwright)

How do we test this? We can't rely on random network lag. We need to deliberately freeze the request for 3 seconds to verify the application's "Patience Logic".

Here is a Playwright test that guarantees the "Zombie UI" never happens:

import time
from playwright.sync_api import Page, Route, expect

def test_slow_network_ux(page: Page):
    # ✅ 1. Setup the "Freeze" Interceptor
    def slow_handler(route: Route):
        print(f"❄️ Freezing request to {route.request.url} for 3s...")
        # Simulate Bad 3G / Subway Network
        # Note: In async tests, use 'await asyncio.sleep(3)'
        time.sleep(3) 
        route.continue_()

    # Intercept the checkout API
    page.route("**/api/checkout", slow_handler)

    page.goto("/cart")

    # ✅ 2. Trigger the Action
    submit_btn = page.locator("#submit-order")
    submit_btn.click()

    # ✅ 3. Assert "Immediate Feedback" (0-100ms)
    # The button must be disabled immediately
    expect(submit_btn).to_be_disabled()

    # ✅ 4. Assert "Loading State" (100-300ms)
    # The spinner must appear while we wait (we have 3 seconds)
    spinner = page.locator(".spinner-loader")
    expect(spinner).to_be_visible()

    # ✅ 5. Assert "Success State" (After 3s)
    # Eventually, the request completes
    expect(page.locator(".success-message")).to_be_visible(timeout=5000)
    # The spinner should disappear
    expect(spinner).not_to_be_visible()

Why automate this?

If you test this manually on localhost, you will blink and miss the spinner. By forcing a 3-second delay in CI, you guarantee that every user—even those on a slow mobile connection—gets a responsive UI, not a dead one.

Architecture Note: CDP vs System Proxy

Why your local tests might be lying to you.

Most network interception tests (like the one above) use the Chrome DevTools Protocol (CDP).

CDP is great for Browsers: It gives you perfect control over traffic inside the Chrome process.
CDP fails on "The Full Matrix": You cannot easily attach CDP to a physical iPhone running Safari, a Smart TV app, or a native Android build.

The "Real World" Reality

If you want to run these Chaos scenarios on real physical devices (not emulators), code-based interception isn't enough.

You need a System Level Proxy (like Charles Proxy or a cloud-native tool like Chaos Proxy Debuggo). These tools sit between the physical device and the internet, allowing you to apply "3G Throttling" or "Random 500 Errors" to a real iPhone without changing a single line of your app's code.

Perceived Performance > Actual Performance.

You cannot always fix the slow SQL query. You cannot fix the user's spotty 4G connection. But you can fix how your UI communicates that delay.

Testing While Developing (Part 6): Using Testing Library Selectors

Sat, 15 Nov 2025 18:48:11 +0000

In this part, we’ll look at a new feature in TWD: support for Testing Library–style selectors.
These selectors are widely known in the community, and while you could technically use them before (TWD is very flexible), now they’re fully integrated — including visual selection in the sidebar.

Before You Start

If you’re following along from Part 5, you can continue as is. But if you want to reset your repo or make sure you're on the correct branch:

# Repo git clone *Emails are not allowed*:BRIKEV/twd-docs-tutorial.git
git reset --hard
git clean -d -f
git checkout 06-selectors-testing-library
npm run serve:dev

Let’s Begin

We’re going to migrate our current twd.get calls (which uses querySelector and we were using data-testid in previous post) to the new Testing Library selectors.

Using screenDom

First, update your src/twd-tests/helloWorld.twd.test.ts file.

// We will change this
const title = await twd.get("[data-testid='welcome-title']");
// to this
const title = await screenDom.getByText("Welcome to TWD");

For assertions, we’ll use a new command: twd.should.
It works exactly like element.should, but can be used with any element returned by screenDom.

Your updated test will look like this:

import { twd, userEvent, screenDom } from "twd-js";
import { describe, it } from "twd-js/runner";

describe("Hello World Page", () => {
  it("should display the welcome title and counter button", async () => {
    await twd.visit("/");
    
    const title = await screenDom.getByText("Welcome to TWD");
    twd.should(title, 'be.visible');
    
    const counterButton = await screenDom.getByText("Count is 0");
    twd.should(counterButton, 'be.visible');
    
    await userEvent.click(counterButton);
    twd.should(counterButton, 'have.text', 'Count is 1');
    
    await userEvent.click(counterButton);
    twd.should(counterButton, 'have.text', 'Count is 2');
    
    await userEvent.click(counterButton);
    twd.should(counterButton, 'have.text', 'Count is 3');
  });
});

You can mix both approaches.
twd.get includes a built-in .should, while screenDom lets you use familiar Testing Library selectors, combined with twd.should.

Todo list Tests

Here’s how the Todo tests look after migrating to testing-library selectors:

import { twd, expect, userEvent, screenDom } from "twd-js";
import { describe, it, beforeEach } from "twd-js/runner";
import todoListMock from "./mocks/todoList.json";

describe("Todo List Page", () => {
  beforeEach(() => {
    twd.clearRequestMockRules();
  });

  it("should display the todo list", async () => {
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: todoListMock,
      status: 200,
    });
    await twd.visit("/todos");
    await twd.waitForRequest("getTodoList");
    
    const todo1Title = await screenDom.getByText("Learn TWD");
    twd.should(todo1Title, "be.visible");
    
    const todo2Title = await screenDom.getByText("Build Todo App");
    twd.should(todo2Title, "be.visible");
    
    const todo1Description = await screenDom.getByText("Understand how to use TWD for testing web applications");
    twd.should(todo1Description, "be.visible");
    
    const todo2Description = await screenDom.getByText("Create a todo list application to demonstrate TWD features");
    twd.should(todo2Description, "be.visible");
    
    const todo1Date = await screenDom.getByText("Date: 2024-12-20");
    twd.should(todo1Date, "be.visible");
    
    const todo2Date = await screenDom.getByText("Date: 2024-12-25");
    twd.should(todo2Date, "be.visible");
  });

  it("should create a todo", async () => {
    await twd.mockRequest("createTodo", {
      method: "POST",
      url: "/api/todos",
      response: todoListMock[0],
      status: 200,
    });
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: [],
      status: 200,
    });
    await twd.visit("/todos");
    await twd.waitForRequest("getTodoList");
    
    const noTodosMessage = await screenDom.getByText("No todos yet. Create one above!");
    twd.should(noTodosMessage, "be.visible");
    
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: [
        todoListMock[0]
      ],
      status: 200,
    });
    
    const titleInput = await screenDom.getByLabelText("Title");
    await userEvent.type(titleInput, "Test Todo");
    
    const descriptionInput = await screenDom.getByLabelText("Description");
    await userEvent.type(descriptionInput, "Test Description");
    
    const dateInput = await screenDom.getByLabelText("Date");
    await userEvent.type(dateInput, "2024-12-20");
    
    const submitButton = await screenDom.getByRole("button", { name: "Create Todo" });
    await userEvent.click(submitButton);
    
    await twd.waitForRequest("getTodoList");
    const rule = await twd.waitForRequest("createTodo");
    expect(rule.request).to.deep.equal({
      title: "Test Todo",
      description: "Test Description",
      date: "2024-12-20",
    });

    const todoList = await screenDom.getAllByText(/Learn TWD|Build Todo App|Test Todo/);
    expect(todoList).to.have.length(1);
  });

  it("should delete a todo", async () => {
    await twd.mockRequest("deleteTodo", {
      method: "DELETE",
      url: "/api/todos/1",
      response: null,
      status: 200,
    });
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: todoListMock,
      status: 200,
    });
    await twd.visit("/todos");
    
    // Find the delete button for the first todo (Learn TWD)
    // Since there are multiple delete buttons, we'll get all and use the first one
    // which corresponds to the first todo item
    const deleteButtons = await screenDom.getAllByRole("button", { name: "Delete" });
    const deleteButton = deleteButtons[0];
    
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: todoListMock.filter((todo) => todo.id !== "1"),
      status: 200,
    });
    
    await userEvent.click(deleteButton);
    await twd.waitForRequest("deleteTodo");
    await twd.waitForRequest("getTodoList");
    
    const todoList = await screenDom.getAllByText(/Learn TWD|Build Todo App/);
    expect(todoList).to.have.length(1);
    twd.should(todoList[0], "be.visible");
  });
});

Conclusion

As you can see, TWD is flexible enough to support both styles of selectors.
And remember: these tests run inside your actual application, so anything your app can access—stores, utilities, helpers—can be used to set up your scenarios.

TWD is all about keeping testing close to development, while staying simple, flexible, and intuitive.

More posts coming soon. More info in our official docs.

Testing While Developing (Part 5): Collecting Coverage

Sat, 15 Nov 2025 18:28:47 +0000

TWD still has many more advanced features — such as function mocking — but with what we’ve covered so far, you already have everything a solid testing tool needs.
In this step, we’ll see how to collect code coverage from your TWD tests and visualize it locally or in CI.

Before You Start

If you’re following along from Part 4, you can continue as is. But if you want to reset your repo or make sure you're on the correct branch:

# Repo git clone *Emails are not allowed*:BRIKEV/twd-docs-tutorial.git
git reset --hard
git clean -d -f
git checkout 05-coverage
npm run serve:dev

Instrumenting the Vite App

We’ll use the vite-plugin-istanbul plugin to instrument our code and generate coverage data.

npm i --save-dev vite-plugin-istanbul

Then, open your vite.config.ts and add the plugin:

/// <reference types="vitest" />
import path from "path"
import tailwindcss from "@tailwindcss/vite"
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
// add plugin for code coverage
import istanbul from 'vite-plugin-istanbul';

// https://vite.dev/config/
export default defineConfig({
  plugins: [
    react(),
    tailwindcss(),
    // configure istanbul plugin
    istanbul({
      include: 'src/**/*',
      exclude: ['node_modules', 'tests/'],
      extension: ['.ts', '.tsx'],
      requireEnv: process.env.CI ? true : false,
    }),
  ],
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src"),
    },
  },
  server: {
    watch: {
      ignored: ["**/data/data.json", "**data/routes.json"],
    },
  },
})

This plugin automatically adds coverage data to window.__coverage__, which means we can later extract it from Puppeteer during our CI run.

Updating the Puppeteer Script

Let’s update our scripts/run-tests-ci.js script to collect that coverage and save it locally:

import fs from 'fs';
import path from 'path';
import puppeteer from "puppeteer";
import { reportResults } from 'twd-js/runner-ci';

// Determine project root
let __dirname = path.resolve();

const browser = await puppeteer.launch({
  headless: true,
  args: ['--no-sandbox', '--disable-setuid-sandbox'],
});
const page = await browser.newPage();
console.time('Total Test Time');
try {
  // Navigate to your development server
  console.log('Navigating to http://localhost:5173 ...');
  await page.goto('http://localhost:5173');
  // wait to load data-testid="twd-sidebar"
  await page.waitForSelector('[data-testid="twd-sidebar"]', { timeout: 10000 });
  console.log('Page loaded. Starting tests...');
  // reload page
  // Execute all tests
  const { handlers, testStatus } = await page.evaluate(async () => {
    const TestRunner = window.__testRunner;
    const testStatus = [];
    const runner = new TestRunner({
      onStart: () => {},
      onPass: (test) => {
        testStatus.push({ id: test.id, status: "pass" });
      },
      onFail: (test, err) => {
        testStatus.push({ id: test.id, status: "fail", error: err.message });
      },
      onSkip: (test) => {
        testStatus.push({ id: test.id, status: "skip" });
      },
    });
    const handlers = await runner.runAll();
    return { handlers: Array.from(handlers.values()), testStatus };
  });
  console.log(`Tests to report: ${testStatus.length}`);
  
  // Display results in console
  reportResults(handlers, testStatus);

  // --- Collect coverage ---
  const coverage = await page.evaluate(() => window.__coverage__);
  if (coverage) {
    console.log('Collecting code coverage data...');
    const coverageDir = path.resolve(__dirname, './coverage');
    const nycDir = path.resolve(__dirname, './.nyc_output');
    if (!fs.existsSync(nycDir)) {
      fs.mkdirSync(nycDir);
    }
    if (!fs.existsSync(coverageDir)) {
      fs.mkdirSync(coverageDir);
    }
    const coveragePath = path.join(nycDir, 'out.json');
    fs.writeFileSync(coveragePath, JSON.stringify(coverage));
    console.log(`Code coverage data written to ${coveragePath}`);
  } else {
    console.log('No code coverage data found.');
  }

  // Exit with appropriate code
  const hasFailures = testStatus.some(test => test.status === 'fail');
  console.timeEnd('Total Test Time');
  process.exit(hasFailures ? 1 : 0);
  
} catch (error) {
  console.error('Error running tests:', error);
  process.exit(1);
} finally {
  console.log('Closing browser...');
  await browser.close();
}

Updating package.json Scripts

{
  "scripts": {
    // ...
    "dev:ci": "CI=true VITE_COVERAGE=true vite",
    "test:ci": "node scripts/run-tests-ci.js",
    "collect:coverage:html": "npx nyc report --reporter=html --report-dir=coverage",
    "collect:coverage:lcov": "npx nyc report --reporter=lcov --report-dir=coverage",
    "collect:coverage:text": "npx nyc report --reporter=text --report-dir=coverage"
  }
}

Now, run these in two terminals:

npm run dev:ci

And in another terminal:

npm run test:ci

Once the tests complete, you can generate coverage reports in different formats:

npm run collect:coverage:html
npm run collect:coverage:lcov
npm run collect:coverage:text

You’ll see something like this:

Adding Coverage to GitHub Actions

To include the coverage output in your GitHub Action, just update your existing CI workflow:

name: CI - PR Tests

on:
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

      - name: Setup Node.js
        uses: actions/setup-node@v5
        with:
          node-version: 24
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Start Vite dev server
        run: |
          nohup npm run dev:ci > vite.log 2>&1 &
          npx wait-on http://localhost:5173
        env:
          CI: true

      - name: Run Puppeteer tests (test:ci)
        run: npm run test:ci
        env:
          CI: true
      
      - name: Display coverage
        run: |
          npm run collect:coverage:text

With the new Display coverage step, you’ll see the coverage summary directly in your GitHub Action logs:

Having this basic configuration, it’s entirely up to you how you want to handle the coverage results.
You can publish them to a service like Codecov or Coveralls, display them as badges in your README, or even use them in your CI pipeline to fail a build if coverage drops below a threshold.
What matters is that the library gives you the flexibility to collect and track coverage directly from your browser tests, without relying on a separate test runner.

Conclusion

And that’s it — we’ve reached the end of the TWD tutorial series!

Throughout these five parts, we’ve built a complete workflow from zero to production-ready testing:

Setup and first visit test
Selectors, assertions, and user events
Network mocking
CI integration with Puppeteer
Code coverage collection and reporting

With this foundation, you can now test your apps as you develop them, keeping your environment close to what your users actually see — which is what TWD (Test While Developing) is all about.

Thanks for following along, and happy testing!
You can always explore more in our official docs.

Testing While Developing (Part 4): Running Tests in CI

Sat, 15 Nov 2025 18:18:42 +0000

In Part 3, we explored one of TWD’s core features — network mocking — and completed our first full set of tests.
Now, it’s time to take the next step: running those tests in the terminal so we can integrate them into a CI workflow.

To do this, we’ll use Puppeteer and one of TWD’s utilities, reportResults, to display test results directly in the console.

Before You Start

If you’re following along from Part 3, you can continue as is. But if you want to reset your repo or make sure you're on the correct branch:

# Repo git clone *Emails are not allowed*:BRIKEV/twd-docs-tutorial.git
git reset --hard
git clean -d -f
git checkout 04-ci-integration
npm run serve:dev

Running Tests in the Terminal

TWD exposes its runner on the window object, which means you can programmatically execute your tests from any environment — including tools like Puppeteer.

Here’s the basic version of that script:

import { reportResults } from 'twd-js/runner-ci';

const TestRunner = window.__testRunner;
const testStatus = [];
const runner = new TestRunner({
  onStart: () => {},
  onPass: (test) => {
    testStatus.push({ id: test.id, status: "pass" });
  },
  onFail: (test, err) => {
    testStatus.push({ id: test.id, status: "fail", error: err.message });
  },
  onSkip: (test) => {
    testStatus.push({ id: test.id, status: "skip" });
  },
});
const handlers = await runner.runAll();
// report results
reportResults(handlers, testStatus);

That’s the core logic we need to run TWD tests headlessly — but we still need a way to access the window context.
Let’s do that by using Puppeteer.

Step 1. Install Dependencies

npm install --save-dev puppeteer

Step 2. Create a CI Script

Let’s create a new file: scripts/run-tests-ci.js:

import puppeteer from "puppeteer";
import { reportResults } from 'twd-js/runner-ci';

const browser = await puppeteer.launch({
  headless: true,
  args: ['--no-sandbox', '--disable-setuid-sandbox'],
});
const page = await browser.newPage();
console.time('Total Test Time');
try {
  // Navigate to your development server
  console.log('Navigating to http://localhost:5173 ...');
  await page.goto('http://localhost:5173');
  // wait to load data-testid="twd-sidebar"
  await page.waitForSelector('[data-testid="twd-sidebar"]', { timeout: 10000 });
  console.log('Page loaded. Starting tests...');
  // reload page
  // Execute all tests
  const { handlers, testStatus } = await page.evaluate(async () => {
    const TestRunner = window.__testRunner;
    const testStatus = [];
    const runner = new TestRunner({
      onStart: () => {},
      onPass: (test) => {
        testStatus.push({ id: test.id, status: "pass" });
      },
      onFail: (test, err) => {
        testStatus.push({ id: test.id, status: "fail", error: err.message });
      },
      onSkip: (test) => {
        testStatus.push({ id: test.id, status: "skip" });
      },
    });
    const handlers = await runner.runAll();
    return { handlers: Array.from(handlers.values()), testStatus };
  });
  console.log(`Tests to report: ${testStatus.length}`);
  
  // Display results in console
  reportResults(handlers, testStatus);

  // Exit with appropriate code
  const hasFailures = testStatus.some(test => test.status === 'fail');
  console.timeEnd('Total Test Time');
  process.exit(hasFailures ? 1 : 0);
  
} catch (error) {
  console.error('Error running tests:', error);
  process.exit(1);
} finally {
  console.log('Closing browser...');
  await browser.close();
}

Step 3. Add the Script to package.json

{
  "scripts": {
    // ...
    "test:ci": "node scripts/run-tests-ci.js"
  }
}

Now, with your development server running in another terminal, execute:

npm run test:ci

And you should see something like this:

GitHub Actions Integration

We’re still working on a built-in CI solution, but for now you can easily integrate TWD with GitHub Actions using Puppeteer.

Create a file at .github/workflows/ci.yml:

name: CI - PR Tests

on:
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

      - name: Setup Node.js
        uses: actions/setup-node@v5
        with:
          node-version: 24
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Start Vite dev server
        run: |
          nohup npm run dev > vite.log 2>&1 &
          npx wait-on http://localhost:5173
        env:
          CI: true

      - name: Run Puppeteer tests (test:ci)
        run: npm run test:ci
        env:
          CI: true

And that’s it — your tests will now run automatically in CI.

What’s Next

We’ve learned how TWD integrates smoothly into CI workflows.
The next step is to collect code coverage, the last missing piece of most testing setups — and that’s exactly what we’ll cover in the next post.

You can always check out our official docs to learn more.

Testing While Developing (Part 3): Mocking API Requests

Sat, 15 Nov 2025 18:16:54 +0000

In Part 2, we explored assertions, selectors, and user interactions in TWD.
We used those tools to test the homepage, which only had a single button.

Now, it’s time to move to the /todos page — which brings more realistic functionality:

Display Todos
Create Todos
Remove Todos

This page uses an API created with json-server.
We could run our tests directly against the real API like before, but that would modify local data and require resetting the database between tests. That’s not ideal — we want each test to be fully independent.

That’s where mocking comes in.

In TWD, we recommend mocking your network requests so you can test your frontend without backend dependencies. This approach brings several advantages:

You can simulate any scenario: success, errors, or missing data.
You can validate the UX for those edge cases.
You can reproduce bugs easily by mocking the exact request that caused them.

To achieve this, TWD provides utilities for mocking requests using Service Workers that intercept network traffic.

Let’s dive in.

Before You Start

If you’re following along from Part 2, you can continue as is. But if you want to reset your repo or make sure you're on the correct branch:

# Repo git clone *Emails are not allowed*:BRIKEV/twd-docs-tutorial.git
git reset --hard
git clean -d -f
git checkout 03-network-mocking
npm run serve:dev

Installing the Service Worker

We have a command to install the Service Worker that handles request interception:

npx twd-js init public --save

This command creates a mock-sw.js file in the folder you specify.
Since we’re using Vite, it will be stored inside the public folder.

After that, initialize the worker in your src/main.tsx file:

if (import.meta.env.DEV) {
  // You choose how to load the tests; this example uses Vite's glob import
  const testModules = import.meta.glob("./**/*.twd.test.ts");
  const { initTests, twd, TWDSidebar } = await import('twd-js');
  // You need to pass the test modules, the sidebar component, and createRoot function
  initTests(testModules, <TWDSidebar open={true} position="left" />, createRoot);
  // if you want to use mock requests, you can initialize it here
  twd.initRequestMocking()
    .then(() => {
      console.log("Request mocking initialized");
    })
    .catch((err) => {
      console.error("Error initializing request mocking:", err);
    });
}

Displaying Todos

Create a new file src/twd-tests/todoList.twd.test.ts and start with a basic test:

import { twd } from "twd-js";
import { describe, it } from "twd-js/runner";

describe("Todo List Page", () => {
  it("should display the todo list", async () => {
    await twd.visit("/todos");
  });
});

This test simply visits the /todos page and loads the real API data:

Now let’s mock the request so we can control the response.

await twd.mockRequest("getTodoList", {
  method: "GET",
  url: "/api/todos",
  response: [],
  status: 200,
});

This method receives an alias and a configuration object — including the HTTP method, URL, mocked response, and status code.
There are more options (check our docs for all available fields).

Now the complete test looks like this:

import { twd } from "twd-js";
import { describe, it } from "twd-js/runner";

describe("Todo List Page", () => {
  it("should display the todo list", async () => {
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: [],
      status: 200,
    });
    await twd.visit("/todos");
  });
});

This will show an empty list — exactly what we defined:

This is extremely powerful because it lets you simulate all possible frontend scenarios — from successful responses to errors — without relying on your backend.
You can even capture real requests from bugs and replay them as tests.

Now let’s build a complete test with real data.

Mocking with Real Data

Create a mock file: src/twd-tests/mocks/todoList.json

[
  {
    "id": "1",
    "title": "Learn TWD",
    "description": "Understand how to use TWD for testing web applications",
    "date": "2024-12-20"
  },
  {
    "id": "2",
    "title": "Build Todo App",
    "description": "Create a todo list application to demonstrate TWD features",
    "date": "2024-12-25"
  }
]

And now the complete test:

import { twd } from "twd-js";
import { describe, it } from "twd-js/runner";
import todoListMock from "./mocks/todoList.json";

describe("Todo List Page", () => {
  it("should display the todo list", async () => {
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: todoListMock,
      status: 200,
    });
    await twd.visit("/todos");
    await twd.waitForRequest("getTodoList");
    const todo1Title = await twd.get("[data-testid='todo-title-1']");
    todo1Title.should("have.text", "Learn TWD");
    const todo2Title = await twd.get("[data-testid='todo-title-2']");
    todo2Title.should("have.text", "Build Todo App");
    const todo1Description = await twd.get("[data-testid='todo-description-1']");
    todo1Description.should("have.text", "Understand how to use TWD for testing web applications");
    const todo2Description = await twd.get("[data-testid='todo-description-2']");
    todo2Description.should("have.text", "Create a todo list application to demonstrate TWD features");
    const todo1Date = await twd.get("[data-testid='todo-date-1']");
    todo1Date.should("have.text", "Date: 2024-12-20");
    const todo2Date = await twd.get("[data-testid='todo-date-2']");
    todo2Date.should("have.text", "Date: 2024-12-25");
  });
});

The new command here is:

await twd.waitForRequest("getTodoList");

It waits until the mocked request is triggered — useful when you need to ensure data is rendered before asserting UI state.

Always define mockRequest before triggering the request (clicks, submits, or navigation).
If you mock it too late, it might not intercept properly.

Creating a Todo

When testing the “create todo” feature, we need to verify:

The form is filled correctly
The correct data is sent
The list refreshes after submission
The new element appears in the list

Let’s define our request mocks first:

// request of creating a todo
await twd.mockRequest("createTodo", {
  method: "POST",
  url: "/api/todos",
  response: todoListMock[0],
  status: 200,
});
// empty list on first load
await twd.mockRequest("getTodoList", {
  method: "GET",
  url: "/api/todos",
  response: [],
  status: 200,
});

Then visit the page and confirm it’s empty:

await twd.visit("/todos");
await twd.waitForRequest("getTodoList");
const noTodosMessage = await twd.get("[data-testid='no-todos-message']");
noTodosMessage.should("be.visible");

Next, update the mock to include a new todo after creation:

await twd.mockRequest("getTodoList", {
  method: "GET",
  url: "/api/todos",
  response: [todoListMock[0]],
  status: 200,
});

Fill and submit the form:

const title = await twd.get("input[name='title']");
await userEvent.type(title.el, "Test Todo");
const description = await twd.get("input[name='description']");
await userEvent.type(description.el, "Test Description");
const date = await twd.get("input[name='date']");
await userEvent.type(date.el, "2024-12-20");
const submitButton = await twd.get("button[type='submit']");
// submit
await userEvent.click(submitButton.el);
// we wait for the list request to be made
await twd.waitForRequest("getTodoList");

Finally, we validate both the request body and updated list:

import { twd, expect, userEvent } from "twd-js";

// all waits return the rule with the definition and request made
const rule = await twd.waitForRequest("createTodo");
// we can validate the request sent to the backend
expect(rule.request).to.deep.equal({
  title: "Test Todo",
  description: "Test Description",
  date: "2024-12-20",
});
const todoList = await twd.getAll("[data-testid='todo-item']");
expect(todoList).to.have.length(1);

expect assertions (from Chai) only show up in the sidebar on failure — unlike .should which always displays. We use Chai as these tests execute in the browser

Full Example

Here’s the complete file, including a best practice: use twd.clearRequestMockRules() in a beforeEach() to ensure every test runs independently.

import { twd, expect, userEvent } from "twd-js";
import { describe, it, beforeEach } from "twd-js/runner";
import todoListMock from "./mocks/todoList.json";

describe("Todo List Page", () => {
  beforeEach(() => {
    twd.clearRequestMockRules();
  });

  // ... display test ...

  it("should create a todo", async () => {
    await twd.mockRequest("createTodo", {
      method: "POST",
      url: "/api/todos",
      response: todoListMock[0],
      status: 200,
    });
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: [],
      status: 200,
    });
    await twd.visit("/todos");
    await twd.waitForRequest("getTodoList");
    await twd.mockRequest("getTodoList", {
      method: "GET",
      url: "/api/todos",
      response: [todoListMock[0]],
      status: 200,
    });
    const noTodosMessage = await twd.get("[data-testid='no-todos-message']");
    noTodosMessage.should("be.visible");
    const title = await twd.get("input[name='title']");
    await userEvent.type(title.el, "Test Todo");
    const description = await twd.get("input[name='description']");
    await userEvent.type(description.el, "Test Description");
    const date = await twd.get("input[name='date']");
    await userEvent.type(date.el, "2024-12-20");
    const submitButton = await twd.get("button[type='submit']");
    await userEvent.click(submitButton.el);
    await twd.waitForRequest("getTodoList");
    const rule = await twd.waitForRequest("createTodo");
    expect(rule.request).to.deep.equal({
      title: "Test Todo",
      description: "Test Description",
      date: "2024-12-20",
    });
    const todoList = await twd.getAll("[data-testid='todo-item']");
    expect(todoList).to.have.length(1);
  });
});

Removing Todos

For deleting todos, we reuse what we’ve learned — mocking, waiting, and validating.

it("should delete a todo", async () => {
  await twd.mockRequest("deleteTodo", {
    method: "DELETE",
    url: "/api/todos/1",
    response: null,
    status: 200,
  });
  await twd.mockRequest("getTodoList", {
    method: "GET",
    url: "/api/todos",
    response: todoListMock,
    status: 200,
  });
  await twd.visit("/todos");
  const deleteButton = await twd.get("[data-testid='delete-todo-1']");
  await twd.mockRequest("getTodoList", {
    method: "GET",
    url: "/api/todos",
    response: todoListMock.filter((todo) => todo.id !== "1"),
    status: 200,
  });
  await userEvent.click(deleteButton.el);
  await twd.waitForRequest("deleteTodo");
  await twd.waitForRequest("getTodoList");
  const todoList = await twd.getAll("[data-testid='todo-item']");
  expect(todoList).to.have.length(1);
});

What's next

We’ve covered one of the most important parts of the TWD approach — mocking.
This is where the framework truly shines.

A few closing thoughts:

Use mocks to test what you’re building — your frontend.
Don’t worry about backend or third-party services during development.
These mocks only intercept client-side requests (SSR is out of scope).
You’ll have all possible scenarios documented as runnable tests — no setup, no servers, just npm i.

We strongly believe this is the most efficient way to develop and test modern SPAs.
It keeps your workflow fast, predictable, and resilient to backend changes.

In the next post, we’ll take things further by adding terminal execution for CI.

Testing While Developing (Part 2): Selectors, Assertions, and User Events

Fri, 14 Nov 2025 19:06:42 +0000

In the previous post, we set up our basic testing configuration and used the visit command to load our app.
Now, we’re ready to make our tests a little more meaningful.

In this part, we’ll focus on three key features:

Selectors – how we find elements in our UI
Assertions – how we verify what’s on screen
User events – how we simulate real interactions

Let’s dive in.

Before You Start

If you’re following along from Part 1, you can continue as is. But if you want to reset your repo or make sure you're on the correct branch:

# Repo git clone *Emails are not allowed*:BRIKEV/twd-docs-tutorial.git
git reset --hard
git clean -d -f
git checkout 02-assertions
npm run serve:dev

Selectors

TWD uses a simple and familiar approach for selectors.
It provides two commands — get and getAll — which are based directly on the native DOM APIs document.querySelector and document.querySelectorAll.

That means you can use any selector you’d normally use in the browser: class, id, tag, attribute, role, etc.
We believe this keeps things flexible and intuitive, especially for developers already comfortable with the DOM.

Let’s improve our existing test file src/twd-tests/helloWorld.twd.test.ts.
We’ll test that our title displays the text “Welcome to TWD” and that our counter button updates as expected.

We’ll start by selecting the elements using twd.get:

const title = await twd.get("[data-testid='welcome-title']");

Here, we’re using a data-testid attribute — just like in React Testing Library or Cypress.
Because get is based on querySelector, you can use any CSS selector you prefer.

For the counter button, we can do the same:

const counterButton = await twd.get("[data-testid='counter-button']");

Note: Selectors are async because TWD automatically retries finding the element for up to two seconds.
So don’t forget to use await before them.

Assertions

Once we’ve selected our elements, it’s time to verify that our UI behaves as expected.

Each selected element returned by twd.get includes two useful properties:

el – the raw DOM element
should – a utility for performing assertions

Here’s how we can assert visibility and text content:

const title = await twd.get("[data-testid='welcome-title']");
title.should("be.visible").should("have.text", "Welcome to TWD");

const counterButton = await twd.get("[data-testid='counter-button']");
counterButton.should("be.visible").should("have.text", "Count is 0");

The should command is chainable, so you can stack multiple conditions easily.
TWD supports several built-in assertions such as:

be.visible
have.text
have.class
have.attribute
and even their not versions (e.g. should("not.have.text", "Error"))

Once you run your tests, the sidebar will clearly show what was tested:

Interacting with the UI

Now that we can find and verify elements, let’s make things interactive.

TWD integrates directly with user event from React Testing Library — a well-known tool that handles realistic user interactions such as clicks, typing, and keyboard input.

We chose user-event because it already supports most common browser interactions and mimics how a real user would use the app.
TWD also provides a custom setInputValue helper for specific inputs that user-event doesn’t handle perfectly.

To use it, import both twd and userEvent:

import { twd, userEvent } from "twd-js";

Then, to simulate a click:

const counterButton = await twd.get("[data-testid='counter-button']");
await userEvent.click(counterButton.el);

Notice we pass the element itself (.el) to userEvent, as that’s what the library expects.

Putting It All Together

Now let’s combine selectors, assertions, and events into a single test.
Our helloWorld.twd.test.ts will look like this:

import { twd, userEvent } from "twd-js";
import { describe, it } from "twd-js/runner";

describe("Hello World Page", () => {
  it("should display the welcome title and counter button", async () => {
    await twd.visit("/");
    
    const title = await twd.get("[data-testid='welcome-title']");
    title.should("be.visible").should("have.text", "Welcome to TWD");
    
    const counterButton = await twd.get("[data-testid='counter-button']");
    counterButton.should("be.visible").should("have.text", "Count is 0");
    
    await userEvent.click(counterButton.el);
    counterButton.should("have.text", "Count is 1");
    
    await userEvent.click(counterButton.el);
    counterButton.should("have.text", "Count is 2");
    
    await userEvent.click(counterButton.el);
    counterButton.should("have.text", "Count is 3");
  });
});

And the test results will look like this:

As you can see, the UI updates in real time — and since it’s your actual app, you can continue using it normally while your tests run.

what's next

In the next post, we’ll explore one of the most powerful features of TWD: network mocking.
This will let developers test their frontend independently, without relying on backend integrations — perfect for building and testing features faster.

You can also learn more about selectors, assertions, and user events in our official docs.

Testing While Developing (Part 1) – Installation and First Test

Fri, 14 Nov 2025 19:03:23 +0000

Let’s start our journey learning how to use TWD (Test While Developing)!
In this first part, we’ll work with a small finished project that includes two pages:

A Hello World page (perfect for our first test)
A Todo List page that makes requests to an API powered by JSON Server

Our goal in this post is to install TWD and add the sidebar that will host all our tests.

Setting Up the Project

We’ll start by setting up our base project. You can clone the repo here:

git clone *Emails are not allowed*:BRIKEV/twd-docs-tutorial.git
cd twd-docs-tutorial
git checkout 01-setup
npm i

This project includes two routes: / and /todos.
All components and pages are already in place — ready for us to test.

To run the project locally:

npm run serve:dev

You should see this:

Getting Started with TWD

Now let’s install TWD:

# You can use npm, yarn, or pnpm
npm i --save-dev twd-js

Once installed, open src/main.tsx and add this code snippet:

if (import.meta.env.DEV) {
  // You choose how to load the tests; this example uses Vite's glob import
  const testModules = import.meta.glob("./**/*.twd.test.ts");
  const { initTests, TWDSidebar } = await import('twd-js');
  // You need to pass the test modules, the sidebar component, and createRoot function
  initTests(testModules, <TWDSidebar open={true} position="left" />, createRoot);
}

It’s important to include this inside the if (import.meta.env.DEV) block — this way, TWD won’t be bundled into your production build.

Once that’s added, you’ll see the TWD Sidebar, where all your tests will appear:

Creating Our First Test

In the snippet above, we’re using this line:

const testModules = import.meta.glob("./**/*.twd.test.ts");

This tells Vite to automatically load every file matching the pattern ./**/*.twd.test.ts.
So let’s create our very first test file.

Create a new file at src/twd-tests/helloWorld.twd.test.ts and add this code:

import { describe, it } from "twd-js/runner";

describe("Hello World Page", () => {
  it("should display the welcome title and counter button", async () => {
    console.log('Executed console.log');
  });
});

Now, your test will appear in the TWD sidebar.
You can click the play icon next to it, or press Run All to execute all tests.
You’ll see the console.log output in your browser console.

This test passes (green) because it doesn’t actually test anything yet.
In the next post, we’ll explore assertions and selectors — the real power of TWD.

Bonus: Visiting a Page

Before we move on, let’s add one small command: twd.visit.

Update your test like this:

import { twd } from "twd-js";
import { describe, it } from "twd-js/runner";

describe("Hello World Page", () => {
  it("should display the welcome title and counter button", async () => {
    await twd.visit('/');
  });
});

This command visits the page exactly like Cypress’s cy.visit() — simple and familiar.

In the next post, we’ll dive into assertions and selectors, where you’ll start interacting with elements and verifying real behavior.

Meanwhile, you can check out the TWD documentation
for more details.

Coder Legion - Recent posts tagged test

Top Staging & Sandbox Tools to Test Site Updates Before Going Live

From Bug Reproduction to Playwright Test — Without Starting From Scratch

n8n Webhook Not Working? Test, Production, and 404 Fixes

Start with the symptom

Test URL versus Production URL

Use the Test URL while building

Use the Production URL after publishing

The n8n webhook 404 checklist

Check the HTTP method before the payload

Check the webhook path

Send a minimal request

Reverse proxy and public URL problems

What to log before handing the webhook into production

The production handoff

Mobile SEO Checklist: Test the Page Google and Customers See

Use three views of the same URL

1. Define the page and task before testing

2. Confirm the same indexable page reaches mobile

3. Compare Google's indexed crawl with the live test

4. Compare mobile and desktop content parity

5. Test navigation without hover or guesswork

6. Check tap targets, zoom, and overlays

7. Complete the form and business action

8. Check responsive media and layout boundaries

9. Test more than one phone context

What not to do

Final mobile SEO validation record

Sources checked

n8n Free Trial: 3 Workflows to Test in 14 Days

Know the trial limits before day one

Prepare the evidence before signup

A practical 14-day schedule

Workflow one: route a qualified lead alert

Workflow two: deliver a weekly operating summary

Workflow three: create a safe invoice reminder

Use the new AI Assistant for one controlled build

Understand what consumes an execution

Run failure drills before you trust the workflows

Use this keep-or-cancel scorecard

Export before the trial ends

Sources checked

Apollo Free Trial: What You Can Test Before Paying

Apollo Free account and free trial are not the same thing

Prepare a small test pack before starting the clock

A practical 14-day Apollo trial schedule

Test one: can Apollo isolate the right market?

Test two: measure contact quality and credit use together

Test three: build one sequence without risking your domain

Test AI Assistant only when it saves a real step

If calling matters, verify dialer access before choosing a trial

What the Apollo trial cannot prove

Choose Basic or Professional by the feature you must prove

Use this upgrade-or-revert scorecard

What not to do during the trial

Sources checked

Go 1.26.2 Released: Security Fixes, Regression Patches, and an Upgrade Playbook

Go 1.26.2 Released: Security Fixes, Regression Patches, and an Upgrade Playbook

TL;DR (beginner + technical)

If you are new: what does "1.26.2" mean?

Why this patch matters technically

Deep look at the Go1.26.2 milestone

What the issue distribution tells us

Security and CVE signal

Regression fixes you may actually notice

Download artifacts and checksum verification

Production-safe upgrade playbook

Copy-paste CI gate (practical baseline)

Should you upgrade now?

Read more

Data provenance

Laravel Testing Environment Setup

published_at: 2026-03-26 14:38 +0000

Stop Building "Zombie UI" The Resilient UX Checklist (Playwright + Python)

Testing While Developing (Part 6): Using Testing Library Selectors

Before You Start

Let’s Begin

Using screenDom

Todo list Tests

Conclusion