{"id":2699,"date":"2025-05-27T17:33:40","date_gmt":"2025-05-27T17:33:40","guid":{"rendered":"https:\/\/www.rainforestqa.com\/blog\/?p=2699"},"modified":"2025-06-04T21:27:45","modified_gmt":"2025-06-04T21:27:45","slug":"when-to-run-e2e-tests","status":"publish","type":"post","link":"https:\/\/www.rainforestqa.com\/blog\/when-to-run-e2e-tests","title":{"rendered":"When to run end-to-end (E2E) tests, explained"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">We sometimes have customers tell us they want to run end-to-end tests as often as possible in their development processes \u2014\u00a0as often as every commit.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When you really care about quality, this might seem like a reasonable idea.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">After all, doesn\u2019t the principle of shift left tell us to test as early as possible in the software development lifecycle? To catch bugs and other issues when they\u2019re the least-expensive to fix?&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Yes, but the principle very much <em>doesn\u2019t <\/em>say, \u201cRun <em>end-to-end<\/em> <em>tests<\/em> as early as possible in the SDLC.\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That\u2019s because there\u2019s a natural tradeoff between quality and speed: spending extra time on quality checks means you sacrifice some of the velocity of your development and release process.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>In this piece, I\u2019m going to make the case that running E2E tests when you\u2019re ready to push a release to your customers \u2014 and no earlier in the development process \u2014 is key to finding a balance between quality and speed in your development cycle.<\/strong>&nbsp;<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_85 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.rainforestqa.com\/blog\/when-to-run-e2e-tests\/#The_balance_between_quality_and_speed\" >The balance between quality and speed<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.rainforestqa.com\/blog\/when-to-run-e2e-tests\/#The_testing_pyramid_when_to_use_different_types_of_tests_and_why\" >The testing pyramid: when to use different types of tests (and why)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.rainforestqa.com\/blog\/when-to-run-e2e-tests\/#The_inverted_test_pyramid_the_risks_of_running_E2E_tests_too_early_and_too_often\" >The inverted test pyramid: the risks of running E2E tests too early and too often<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.rainforestqa.com\/blog\/when-to-run-e2e-tests\/#Your_E2E_testing_action_plan\" >Your E2E testing action plan<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"The_balance_between_quality_and_speed\"><\/span>The balance between quality and speed<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Since both quality and speed are high priorities for performant software teams (and software teams who aspire to be performant), it\u2019s key to find a healthy balance between them. And not err too much in favor of one over the other.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Too much speed inevitably leads to more bugs, more hotfixes, and more tech debt \u2014 which all undermine the momentum and productivity of the team. On the other hand, too much focus on (the wrong kind of) quality assurance bottlenecks the release process, distracts your devs from building, and makes you slower and less competitive.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Running end-to-end tests too early and too often in the software development process sacrifices way too much velocity for a minimal return on quality. It\u2019s usually a sign that you haven\u2019t reached that happy balance between speed and quality. I\u2019d go so far as to say it\u2019s an anti-pattern for teams that ascribe to Agile principles.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>The good news is: you can operate on shift-left principles, feel confident about your test coverage, <\/strong><strong><em>and<\/em><\/strong><strong> ship fast and frequently (i.e., be Agile).&nbsp;<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>You just have to use the right kinds of tests at the right times.<\/strong><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"The_testing_pyramid_when_to_use_different_types_of_tests_and_why\"><\/span>The testing pyramid: when to use different types of tests (and why)<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">You might be familiar with the testing pyramid:<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"731\" height=\"490\" src=\"https:\/\/www.rainforestqa.com\/blog\/wp-content\/uploads\/2024\/10\/testing-pyramid-1.jpeg\" alt=\"\" class=\"wp-image-2700\" style=\"width:650px\" srcset=\"https:\/\/www.rainforestqa.com\/blog\/wp-content\/uploads\/2024\/10\/testing-pyramid-1.jpeg 731w, https:\/\/www.rainforestqa.com\/blog\/wp-content\/uploads\/2024\/10\/testing-pyramid-1-300x201.jpeg 300w\" sizes=\"(max-width: 731px) 100vw, 731px\" \/><figcaption class=\"wp-element-caption\">The testing pyramid (<a href=\"https:\/\/blog.sofwancoder.com\/what-the-testing-pyramid-is-and-why-you-need-to-know-about-it\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">source<\/a>)<\/figcaption><\/figure>\n<\/div>\n\n\n<p class=\"wp-block-paragraph\">The testing pyramid communicates one of the core tenets of modern software testing: a balanced testing strategy applies the right kind of testing method to the right job to optimize for efficiency and effectiveness.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">There are more granular versions of the testing pyramid with even more layers that reflect even more types of tests (like API tests), but we\u2019re going to focus on the three fundamental types of (usually-automated) tests:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Unit tests<\/li>\n\n\n\n<li>Integration tests<\/li>\n\n\n\n<li>End-to-end tests<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Unit tests<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The order of layers in the pyramid corresponds with the stages in which different types of testing should happen in your dev process.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>The testing pyramid puts unit testing at the bottom layer because unit tests should happen in the earliest stages of development.<\/strong> A unit test interacts with a single component or unit of code to validate its functionality, and doesn\u2019t have any external dependencies.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Since the scope of unit tests is inherently so limited:&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Each unit test is computationally inexpensive and executes very quickly (milliseconds or seconds). So you can run unit test cases as early and often as you want \u2014 but at least on every commit on every branch.&nbsp;<\/li>\n\n\n\n<li>You need many of them for sufficient test coverage, especially relative to larger tests like E2E tests. And it&#8217;s ok to have a lot of them because they\u2019re fast and cheap enough to maintain the balance between speed and quality.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">These two points are reflected in the size of each pyramid layer. The size indicates both the relative <em>quantity<\/em> of each type of test you should have, and <em>how often<\/em> you should run that type of test. Large area = more, small area = less.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">End-to-end tests<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">At the other end of the pyramid, we have E2E tests. An end-to-end test covers an entire critical workflow in your app, like a login flow or an \u201cadd a user\u201d flow. Any one of these workflows includes a number of software components, so \u2014 by definition \u2014 it\u2019d take a number of unit tests to cover what a single E2E test covers.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Except you can\u2019t use a number of unit tests to replace an E2E test, because unit tests operate in isolation. One of the jobs of E2E testing is to verify that individual software components produce the expected results when they interact with one another.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">E2E tests are at the top of the pyramid, meaning they come last in the testing process (generally as part of a regression testing suite). And their layer has the smallest size, meaning you shouldn\u2019t have too many of them relative to the number of unit tests and integration tests. (As a rule of thumb, you should only have enough E2E tests to cover your critical frontend application workflows \u2014 not the workflows you wouldn\u2019t fix right away if they broke.)&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">First, you don\u2019t need as many of them for a lot of coverage because they\u2019re inherently broader test cases than unit and integration tests. <strong>Plus,<\/strong> <strong>you shouldn\u2019t have too many of them because E2E test execution is relatively expensive both in compute and in time.&nbsp;<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For example, when our customers run all of their tests in parallel on our platform, they get results back in a few minutes, on average. Our competitors like MuukTest and QA Wolf promise the same results.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A few minutes is pretty fast compared to waiting in line at airport security during the holidays, but it can be disruptive if you\u2019re a developer who\u2019s in the zone and trying to ship.<\/strong> (Just imagine the poor developers running their E2E tests sequentially.)&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">It\u2019s not like you can context-switch and make meaningful progress on a new task in just a few minutes. It takes time for our minds to adjust to new demands.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For the sake of productivity and velocity, interrupting your developers\u2019 flow is something you want to avoid as much as possible. (Which you already knew.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Integration tests<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>But what if you don\u2019t want to wait until you\u2019re ready to release to customers to make sure all your code components are playing nicely together?<\/strong> The answer isn\u2019t to run <em>slow, expensive <\/em>E2E tests earlier in the process.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Implement integration tests<\/strong>. Integration tests verify the interactions between different individual components of a system, but are limited in scope. So they\u2019re broader than unit tests, but not as long and complex as E2E tests that cover entire workflows.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">You don\u2019t have to use special tooling or techniques for satisfactory integration testing. <strong>You could even use the same tooling you already use for E2E testing.<\/strong> (That\u2019s what we do \u2014 we have UI tests in the Rainforest platform that serve as integration and E2E test cases, respectively.)&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The key is to observe the principles of the testing pyramid: have notably fewer tests in your integration test suite than in your unit test suite, and make your integration tests notably shorter than your E2E tests. Instead of covering an entire user workflow like an E2E test, an integration test should only cover a small number of components at a time. This will help you isolate which specific components might be having issues.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Because remember, the goal is to find the right balance between quality and speed. And it\u2019s not a winning move to go overboard with too many long tests too early in your release process. <strong>Integration tests can give you confidence that the most critical interactions between your code components are working properly, without the expense of E2E tests.<\/strong><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"The_inverted_test_pyramid_the_risks_of_running_E2E_tests_too_early_and_too_often\"><\/span>The inverted test pyramid: the risks of running E2E tests too early and too often<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The testing pyramid tells us the basic reason why you shouldn\u2019t run E2E tests too early or too often:<strong> E2E tests are expensive in time relative to other types of tests, so overusing them can throw off the balance between quality and speed.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">As we\u2019ve established, when you run (relatively slow) E2E tests too often, you disrupt the flow of your developers, increase context-switching costs, and literally add to the time spent waiting for tests to complete at each stage of development. (If you\u2019re still using manual testing instead of an automation tool, these problems are multiplied.)&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>But this doesn\u2019t fully capture some of the nuanced ways in which overly-aggressive E2E testing can disrupt your software development process, velocity, and even quality.<\/strong>&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Enter: the inverted test pyramid. The inverted test pyramid is a concept that reflects the too-frequent mistake of running too many large (E2E) tests and too few small (unit and integration) tests.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"724\" height=\"434\" src=\"https:\/\/www.rainforestqa.com\/blog\/wp-content\/uploads\/2024\/10\/inverted-testing-pyramid-1.jpg\" alt=\"\" class=\"wp-image-2701\" style=\"width:650px\" srcset=\"https:\/\/www.rainforestqa.com\/blog\/wp-content\/uploads\/2024\/10\/inverted-testing-pyramid-1.jpg 724w, https:\/\/www.rainforestqa.com\/blog\/wp-content\/uploads\/2024\/10\/inverted-testing-pyramid-1-300x180.jpg 300w\" sizes=\"(max-width: 724px) 100vw, 724px\" \/><figcaption class=\"wp-element-caption\">The inverted testing pyramid (<a href=\"https:\/\/mike-bland.com\/2023\/09\/13\/the-inverted-test-pyramid.html\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">source<\/a>)<\/figcaption><\/figure>\n<\/div>\n\n\n<p class=\"wp-block-paragraph\">Here are just two more real-world scenarios that happen when you align your testing operations with the inverted test pyramid:&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Flaky tests undermine both velocity and confidence<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Sometimes your test environment is underpowered or inconsistent. Often there are tests in your E2E suite that are sensitive to small, intended changes to the app under test.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Either way, all E2E automated testing tools suffer from flaky and brittle tests to one degree or another. These are two different varieties of tests that return false-positive test failures.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>They\u2019re the bane of automated testing \u2014 flaky and brittle tests don\u2019t uncover legitimate bugs, but still require time-consuming review and maintenance to keep the test suite up to date and reliable. All cost, no benefit.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">You can mitigate these issues to some degree. For example, Rainforest uses a unique, <a href=\"https:\/\/www.rainforestqa.com\/ai-accelerated-testing\">patent-pending AI<\/a> that automatically updates the relevant tests when a small, intended change has been detected in the app under test.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But some amount of false-positive test failures will remain. For the time being (and until AI gets a lot \u201csmarter\u201d), it\u2019s simply a feature of automated testing to some extent.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Running E2E tests too often means unnecessarily creating a situation where flaky or brittle tests inevitably return false-positive failures more often.<\/strong> That means someone has to spend even <em>more<\/em> time investigating test failures and updating tests, which bottlenecks the development process.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you use an open source testing framework like Selenium \u2014&nbsp;which is notorious for its brittle tests \u2014 the situation is even worse. Your devs or QA engineers will spend a very unhappy amount of time debugging and fixing tests instead of working on the things you <em>want<\/em> them to be focused on, like building features and adding new test coverage.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Software teams already tend to underestimate <\/strong><a href=\"https:\/\/www.rainforestqa.com\/blog\/test-automation-maintenance\"><strong>the costs of test maintenance<\/strong><\/a><strong> \u2014 and running E2E tests more often than necessary simply escalates those costs.<\/strong> (Where you could be using faster, lower-maintenance unit tests or integration tests, instead.)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Even if you use a test automation service like Rainforest QA where someone else takes the burden of test maintenance off your internal team, you still have to wait for your test failures to get investigated and addressed before you can have full confidence in the quality of a release. (And, again, you\u2019re unnecessarily keeping those resources from focusing on important tasks like writing test coverage for new features.)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>The alternative is deciding to ignore test failures in favor of shipping, which creates an imbalance of favoring speed too much over product quality.<\/strong> And this happens! Because (1) a bunch of notifications about test failures that turn out to be false-positives starts to feel like low-signal noise and (2) devs are incentivized to ship.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ultimately, ignoring even just a few test failures often leads to a destructive cycle: the results of the E2E test suite are ignored, so the value of the test suite is diminished, so less investment goes into the E2E test suite, making it less reliable. Which makes it easier to justify ignoring the test results. Ultimately, quality is put at risk for the sake of speed.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Debugging takes longer<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">When a unit test fails, you know exactly which software component isn\u2019t behaving as expected.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But E2E tests are more complex. They inherently test more components \u2014 and more relationships between components \u2014 at a time, so pinpointing the exact cause of a failure can take longer.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Rainforest provides detailed E2E test results including repro steps, video recordings, HTTP logs, and browser logs to make debugging as easy as possible. But even so, it\u2019ll almost always require more effort to analyze and update a failed E2E test than a unit or integration test.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>When you run E2E tests too often, you\u2019re not just inviting <\/strong><strong><em>more frequent<\/em><\/strong><strong> test maintenance onto your team\u2019s plate \u2014 it\u2019s specifically test maintenance that tends to be <\/strong><strong><em>more expensive<\/em><\/strong><strong>.&nbsp;<\/strong><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Your_E2E_testing_action_plan\"><\/span>Your E2E testing action plan<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">End-to-end automated tests are a valuable part of any test plan \u2014 they cover the most critical end-user workflows in your application, confirming that all the software components under test are operating and interacting as expected.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But they\u2019re also relatively expensive to run \u2014 not just in terms of compute and time, but also in terms of maintenance costs.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">So, following the principles of the testing pyramid, run your E2E tests as the \u201clast line of defense\u201d against bugs before you\u2019re ready to release to your customers. (Often, that means testing before you release to your production environment.)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Earlier in the development process, to balance speed and quality, avoid the temptation to (over)use E2E tests and instead implement unit tests and integration tests.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Learn the reasons why you should only run E2E tests when you&#8217;re ready to release to customers.<\/p>\n","protected":false},"author":28,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2699","post","type-post","status-publish","format-standard","hentry","category-qa-strategy"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/2699","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/users\/28"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/comments?post=2699"}],"version-history":[{"count":4,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/2699\/revisions"}],"predecessor-version":[{"id":3362,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/2699\/revisions\/3362"}],"wp:attachment":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/media?parent=2699"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/categories?post=2699"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/tags?post=2699"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}