{"id":23016,"date":"2025-02-03T02:25:09","date_gmt":"2025-02-03T07:25:09","guid":{"rendered":"https:\/\/qxf2.com\/blog\/?p=23016"},"modified":"2025-02-03T02:25:09","modified_gmt":"2025-02-03T07:25:09","slug":"designing-tests-for-feature-flags","status":"publish","type":"post","link":"https:\/\/qxf2.com\/blog\/designing-tests-for-feature-flags\/","title":{"rendered":"Designing Scalable Tests for Feature Flags"},"content":{"rendered":"

Feature flags<\/a> introduce a layer of dynamic behavior in applications, enabling toggled changes without redeployment. While they empower development and experimentation, they also bring unique challenges to testing. Designing tests around feature flags requires recognizing that one size does not fit all\u2014different scenarios demand different strategies. In this post, we explore a range of approaches to help maintain adaptable, and scalable test suites.<\/p>\n

\n

Context<\/h3>\n

Working with feature flags often starts with creating separate tests for each flag state. While this approach works, exploring more streamlined and scalable strategies can lead to better results. Feature flags add layers of complexity to workflows, making adaptable and creative testing strategies essential. By leveraging flexible approaches, we can maintain clarity, minimize redundancy, and manage growing complexity while ensuring high-quality tests.<\/p>\n

This blog post explores strategies like parameterized tests, feature logic handlers, subclassing, and leveraging pytest fixtures to optimize test execution and design for feature flags. These strategies are adaptable to various workflows and scenarios, ensuring they are applied effectively.<\/p>\n

To illustrate these strategies, I have used examples from Qxf2\u2019s ACC Model App<\/a> \u2014an in-house React application designed to manage Attributes, Components, and Capabilities (ACC) in software projects. Some strategies are drawn from the tests I developed for feature flags implemented in this app, using Qxf2\u2019s Page Object Model framework<\/a>.<\/p>\n

\n

Strategies<\/h3>\n

In this section, I will outline the various strategies I explored and applied to effectively test feature flags for different scenarios. While the example tests demonstrate key concepts, they are simplified for clarity and do not represent complete, production-ready code. Additionally, these snippets don\u2019t reflect Qxf2’s exact coding practices but are tailored to illustrate the strategies discussed.<\/p>\n

1. Separate Tests for Each Flag State<\/h4>\n

Creating separate tests for each feature flag is a reliable strategy for ensuring clarity and thoroughness. Isolating the behavior of the application when a flag is enabled or disabled reduces ambiguity. This approach works well when feature flags introduce significant changes to the UI or workflows. <\/p>\n

Example: Home Page Redesign<\/strong>
\nIn the ACC Model app, on the home page, two buttons Login and Authenticate buttons appear in two locations: in the middle of the page and the navigation bar. The home page redesign introduced a feature flag to control the visibility of these buttons.<\/p>\n

– Feature Flag disabled<\/strong>: Users directly interact with the buttons on the home page or navigation bar.
\n– Feature Flag enabled<\/strong>: The redesign removes the buttons from their original positions and introduces a personalized greeting section on the home page. If the system detects a returning user, it dynamically displays their name in the greeting. New users see the ‘Get Started’ link in the navigation bar. <\/p>\n

Below are the test snippets that illustrate how to validate different feature flag states.
\nEach method used in the test is a page object that encapsulates the actions and validations required to perform that function. These page objects interact with the page elements to perform checks and log the results accordingly.<\/p>\n

Test for Feature Flag OFF<\/h5>\n
\r\ndef test_acc_model_home_page(test_obj):\r\n    \"Validate the home page of the ACC Model application.\"\r\n    try:\r\n        test_obj = PageFactory.get_page_object(\"acc model home page\", base_url=test_obj.base_url)\r\n\r\n        # Step 1: Verify the presence of 'Register' and 'Login' buttons\r\n        result_flag = test_obj.verify_auth_buttons_presence()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"'Register' and 'Login' buttons are present as expected.\",\r\n                            negative=\"'Register' or 'Login' buttons are missing unexpectedly.\")\r\n\r\n        # Step 2: Verify the 'Register' functionality\r\n        result_flag = test_obj.verify_register_flow()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Successfully initiated the 'Register' flow.\",\r\n                            negative=\"Failed to initiate the 'Register' flow.\")\r\n\r\n        # Step 3: Verify the 'Login' functionality\r\n        result_flag = test_obj.verify_login_flow()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Successfully initiated the 'Login' flow.\",\r\n                            negative=\"Failed to initiate the 'Login' flow.\")\r\n\r\n# Output the results.\r\n        test_obj.write_test_summary()\r\n         \r\n        ...\r\n\r\n<\/pre>\n
Test for Feature Flag ON<\/h5>\n
\r\ndef test_redesigned_acc_model_home_page(test_obj, setup_flag):\r\n    \"Validate the redesigned home page of the ACC Model application with feature flag enabled.\"\r\n    try:\r\n        test_obj = PageFactory.get_page_object(\"acc model home page\", base_url=test_obj.base_url)\r\n\r\n        # Step 1: Verify the absence of 'Register' and 'Login' buttons (as they are removed in the redesign)\r\n        result_flag = test_obj.verify_auth_buttons_absence()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"'Register' and 'Login' buttons are absent as expected.\",\r\n                            negative=\"'Register' or 'Login' buttons are unexpectedly present.\")\r\n\r\n        # Step 2: Verify the personalized greeting is displayed for a returning user\r\n        result_flag = test_obj.verify_personalized_greeting()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Personalized greeting is displayed for returning user.\",\r\n                            negative=\"Personalized greeting is missing for returning user.\")\r\n\r\n        # Step 3: Verify the \"Get Started\" link is present for new users\r\n        result_flag = test_obj.verify_get_started_link_presence()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"'Get Started' link is present for new users as expected.\",\r\n                            negative=\"'Get Started' link is missing for new users.\")\r\n\r\n        # Step 4: Check for other relevant changes specific to the redesign\r\n        result_flag = test_obj.verify_navigation_bar_update()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Navigation bar updates are correctly reflected.\",\r\n                            negative=\"Navigation bar updates are not as expected.\")\r\n\r\n        # Output the results.\r\n        test_obj.write_test_summary()\r\n\r\n        ...\r\n\r\n<\/pre>\n
This is generally how tests are structured to validate different feature flag states. In practice, we organize these tests into separate functions within a module, each targeting specific scenarios. This modular approach helps maintain clarity and simplifies maintenance. However, relying solely on this strategy may not always be the best option. It can lead to redundant tests and reduced efficiency, especially when changes are minor. Testers should evaluate whether splitting tests adds value or just increases maintenance effort.<\/p>\n
2. Parametrized Tests<\/h4>\n
So far, we have explored separate tests for different feature flag states. However, another effective strategy is to use parameterized tests, which allow us to toggle flag states within a single test suite. This approach is particularly useful when the underlying workflow stays consistent, even if the UI changes significantly. When the UI redesign primarily involves changes to how web elements like buttons and other components display, we can conditionally check locators and elements based on the flag state.<\/p>\n
Example: Edit User Redesign on the Manage Users Page<\/strong>
\nIn the ACC Model app, one of the pages lists the Users of the app with Edit and Delete buttons for each row. The feature flag helped with the redesign of the Edit User functionality.<\/p>\n
– Feature Flag disabled<\/strong>: Clicking Edit opens a modal pop-up, where the user can update the email address and then save the changes.
\n– Feature Flag enabled<\/strong>: Clicking Edit now makes the row inline editable, allowing the user to update the email address directly within the row and save the changes.<\/p>\n
The overall flow remains the same: navigate to the page, edit a user\u2019s email, and save changes. However, the UI interactions differ based on the flag state, such as how editing is initiated and saved.<\/p>\n
Test Code<\/h5>\n
Since the change in the redesign is mostly around different web elements, we can dynamically select locators based on the flag state in the page objects. <\/p>\n
\r\nclass ACCModelUsersPage(Web_App_Helper):\r\n    \"Page object for the Users page of the ACC Model Application\"\r\n\r\n    # common locators\r\n    username_login = locators.username_login\r\n    password_login = locators.password_login\r\n    login_button = locators.login_button\r\n\r\n    def set_locators(self, feature_flag_state):\r\n        \"\"\"\r\n        Set locators dynamically based on feature flag state.\r\n        \"\"\"\r\n        if feature_flag_state:\r\n            self.edit_button = locators.edit_button_inline\r\n            self.save_button = locators.save_button_inline\r\n            self.email_field = locators.email_field_inline\r\n        else:\r\n            self.edit_button = locators.edit_button\r\n            self.save_button = locators.save_button_edit_form\r\n            self.email_field = locators.email_edit_form\r\n\r\n<\/pre>\n
Importantly, while the locators differ, the actual page object methods remain common, minimizing code duplication.<\/p>\n
\r\n@Wrapit._exceptionHandler\r\ndef click_edit_button(self):\r\n    \"\"\"\r\n    Click the Edit button on the user row.\r\n    \"\"\"\r\n    result_flag = self.click_element(self.edit_button)\r\n    self.conditional_write(\r\n        result_flag,\r\n        positive=\"Clicked the Edit button successfully.\",\r\n        negative=\"Failed to click the Edit button.\",\r\n        level='debug'\r\n    )\r\n    return result_flag\r\n\r\n...\r\n<\/pre>\n
We then write the tests to validate the core functionality without duplication. Using pytest.mark.parametrize, we can dynamically toggle the flag state and test both scenarios.<\/p>\n
\r\n@pytest.mark.parametrize(\"feature_flag_state\", [False, True])\r\n@pytest.mark.GUI\r\ndef test_manage_users_page(test_obj, feature_flag_state):\r\n    \"Test the manage users page with or without the feature flag\"\r\n    try:\r\n        test_obj = PageFactory.get_page_object(\"manage users page\", base_url=test_obj.base_url)\r\n\r\n        test_obj.set_locators(feature_flag_state)\r\n\r\n        result_flag = test_obj.login(conf.name, conf.password)\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Logged in successfully.\",\r\n                            negative=\"Failed to login.\"\r\n                            )\r\n\r\n        result_flag = test_obj.click_on_users_link()\r\n        test_obj.log_result(\r\n            result_flag,\r\n            positive=\"Successfully navigated to the Manage Users page.\",\r\n            negative=\"Failed to navigate to the Manage Users page.\",\r\n        )\r\n\r\n        result_flag = test_obj.click_edit_button()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Clicked on the Edit button.\",\r\n                            negative=\"Failed to click on the Edit button.\"\r\n                            )\r\n        \r\n        result_flag = test_obj.update_email()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Updated the email in the Edit form.\",\r\n                            negative=\"Failed to update the email in the Edit form.\"\r\n                            )\r\n        \r\n        result_flag = test_obj.click_save_button()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Clicked on the Save button.\",\r\n                            negative=\"Failed to click on the Save button.\"\r\n                            )\r\n        \r\n        test_obj.write_test_summary()\r\n\r\n       ....\r\n<\/pre>\n
3. Subclassing Page Objects<\/h4>\n
When feature flags result in different UI versions or functionalities, it’s important to structure tests in a way that can easily adapt to these changes. A good approach lets us reuse shared functionality while isolating feature-specific differences. Subclassing page objects offers a practical solution to this, striking a balance between flexibility and maintainability.<\/p>\n
Example: Differentiated UI Features on the Manage Users Page<\/strong>
\nExtending the earlier use case of the Manage Users page redesign, this scenario highlights specific functionalities that differ between the old and new UIs.<\/p>\n
– Feature Flag disabled<\/strong>: Supports the sorting of users
\n– Feature Flag enabled<\/strong>: Replaces sorting with a filtering feature<\/p>\n
Here, the core workflow (e.g., navigating to the page, editing user details) remains the same, but feature-specific functionality like sorting or filtering requires distinct handling. We can address this by subclassing UI-specific functionality. A base class handles the shared functionality, while subclasses manage the UI-specific features.<\/p>\n
Test Code<\/h5>\n
Base Class: Contains shared functionality (eg: login, navigation, common actions).<\/p>\n
\r\nclass ACCModelUsersPage(Web_App_Helper):\r\n    \"Page object for the Users page of the ACC Model Application\"\r\n   \r\n    def login(self, username, password):\r\n        # Logic for entering username, password, and clicking login\r\n        return result_flag\r\n<\/pre>\n
Subclass for Old UI: Handles sorting functionality.<\/p>\n
\r\nclass ACCModelUsersOldUIPage(ACCModelUsersPage):\r\n    \"\"\"\r\n    Page object for the old UI version of the Users page in the ACC Model Application.\r\n    \"\"\"\r\n    def sort_users(self):\r\n        # Logic for sorting users\r\n        return result_flag\r\n\r\n<\/pre>\n
Subclass for New UI: Handles filtering functionality.<\/p>\n
\r\nclass ACCModelUsersNewUIPage(ACCModelUsersPage):\r\n    \"\"\"\r\n    Page object for the new UI version of the Users page in the ACC Model Application.\r\n    \"\"\"\r\n    def filter_users(self):\r\n        # Logic for filtering users\r\n        return result_flag\r\n<\/pre>\n
Dynamically Mapping Page Objects<\/h5>\n
We use PageFactory to dynamically select the correct page object based on the feature flag state.
\nAfter defining the necessary subclasses, we dynamically assign the correct page object based on the feature flag state.<\/p>\n
\r\nclass PageFactory():\r\n    \"PageFactory uses the factory design pattern.\"\r\n    @staticmethod\r\n    def get_page_object(page_name, feature_flag_state=None, base_url=url_conf.ui_base_url):\r\n        \"Return the appropriate page object based on page_name\"\r\n        test_obj = None\r\n        page_name = page_name.lower()\r\n        if page_name in [\"zero\",\"zero page\",\"agent zero\"]:\r\n            from page_objects.zero_page import Zero_Page\r\n            test_obj = Zero_Page(base_url=base_url)\r\n        elif page_name == \"manage users page\":\r\n            if feature_flag_state:\r\n                from page_objects.examples.acc_model_app.users_page import ACCModelUsersNewUIPage\r\n                test_obj = ACCModelUsersNewUIPage(base_url)\r\n            else:\r\n                from page_objects.examples.acc_model_app.users_page import ACCModelUsersOldUIPage\r\n                test_obj = ACCModelUsersOldUIPage(base_url)\r\n        return test_obj\r\n<\/pre>\n
In the base class, we define a method to handle feature-specific actions. Depending on the feature flag state, this method delegates to the appropriate functionality such as filtering users or sorting users (for this example). The core logic remains the same across feature variations, but the specifics are isolated in the subclasses.<\/p>\n
\r\nclass ACCModelUsersPage(Web_App_Helper):\r\n    \"Page object for the Users page of the ACC Model Application\"\r\n\r\n    def set_feature_flag(self, feature_flag_state):\r\n        \"Set the feature flag state\"\r\n        self.feature_flag_state = feature_flag_state\r\n   \r\n    def perform_feature_specific_action(self):\r\n        \"\"\"\r\n        Decide what action to perform based on the feature flag state.\r\n        \"\"\"\r\n        if self.feature_flag_state:\r\n            if hasattr(self, 'filter_users'):\r\n                return self.filter_users()\r\n            else:\r\n                raise NotImplementedError('Subclasses must define filter_users method')\r\n        else:\r\n            if hasattr(self, 'sort_users'):\r\n                return self.sort_users()\r\n            else:\r\n                raise NotImplementedError('Subclasses must define sort_users method')\r\n<\/pre>\n
In the test, we pass the feature_flag_state to dynamically load the correct page object and perform the relevant actions. The test code stays focused on executing the common logic, while the feature-specific actions are handled based on the feature flag.<\/p>\n
\r\n@pytest.mark.parametrize(\"feature_flag_state\", [False, True])\r\n@pytest.mark.GUI\r\ndef test_manage_users_page(test_obj, feature_flag_state):\r\n    \"Test the manage users page with or without the feature flag\"\r\n    try:\r\n        # Create a test object.\r\n        test_obj = PageFactory.get_page_object(\"manage users page\", feature_flag_state, base_url=test_obj.base_url)\r\n        test_obj.set_feature_flag(feature_flag_state)\r\n        test_obj.set_locators()\r\n\r\n        # Perform common actions\r\n        result_flag = test_obj.login(conf.name, conf.password)\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Logged in successfully.\",\r\n                            negative=\"Failed to login.\"\r\n                            )\r\n\r\n        # Other common actions\r\n        \r\n        # Execute feature-specific methods\r\n        result_flag = test_obj.perform_feature_specific_action()\r\n        test_obj.log_result(result_flag,\r\n                            positive=\"Successfully performed feature specific actions.\",\r\n                            negative=\"Failed to perform feature specific actions.\"\r\n                            )\r\n        \r\n        test_obj.write_test_summary()\r\n<\/pre>\n
This approach allows us to reuse common functionality, such as login and navigation, while isolating feature-specific actions like sorting or filtering.<\/p>\n
Both subclassing and parameterized tests effectively manage UI changes driven by feature flags, particularly when core functionality remains consistent despite UI variations. By isolating feature-specific logic, these approaches preserve shared functionality across versions, keeping tests organized and reusable. <\/p>\n
However, as feature flags grow, managing subclasses and variations becomes complex, potentially leading to tightly coupled test logic. To address this, use external configuration files to dynamically map flags to behaviors, minimizing duplication and simplifying maintenance. For multi-variant flags, implement dynamic method selection in the base class to handle specific actions based on flag states. Proper test suite design is essential\u2014breaking tests into smaller, reusable modules ensures adaptability to different flag states while keeping tests clean, scalable, and maintainable, even as complexity increases.<\/p>\n
Managing Feature Flag States with Fixtures<\/h3>\n
So far, we have explored strategies for designing tests around feature flags. Managing feature flags depends on how they are implemented. In staging or test environments, where testers can control feature flags through an endpoint, REST API, or similar mechanism, fixtures provide an effective solution. They dynamically configure the test environment based on the flag state, centralizing setup and teardown logic. By toggling the flag within the fixture, testers can precisely control the application\u2019s behavior for each test case.<\/p>\n
Below is an example of designing fixtures to streamline test management when feature flags are programmatically accessible. If your flags are managed through a configuration file, the implementation would differ. This example focuses on demonstrating the efficiency of fixtures, though the specifics depend on your application\u2019s feature flag setup.<\/p>\n
1. Initializing the Flag Manager<\/h5>\n
We define a fixture to initialize the flag manager, which could be self-hosted or a third-party service like LaunchDarkly. In this example, I have used LaunchDarklyFlagManager.<\/p>\n
\r\n@pytest.fixture(scope=\"module\")\r\ndef flag_manager(): \r\n    \"\"\"Initialize the LaunchDarklyFlagManager instance for the test module.\"\"\"\r\n    return LaunchDarklyFlagManager()\r\n<\/pre>\n
This initializes an instance of the flag manager at the module level, allowing it to be reused across all tests in the module. The LaunchDarklyFlagManager class would include methods for setting and retrieving feature flag values.<\/p>\n
2. Setting the Initial State of the Flag<\/h5>\n
We then define a fixture to ensure that every test starts with a predefined flag state, regardless of the current flag value. This avoids test flakiness caused by leftover states from other tests.<\/p>\n
\r\n@pytest.fixture(scope=\"function\")\r\ndef set_flag_initial_state(flag_manager): \r\n    \"\"\"Set feature flags before running a test.\"\"\"\r\n    flag_manager.set_flag(\"hideAuthButtons\", \"OFF\")\r\n<\/pre>\n
The scope of this fixture is set to function so it resets the flag state before each test. This ensures isolation, as each test starts with the same known state.<\/p>\n
3. Toggling the Feature Flag<\/h5>\n
Next, we define a fixture to toggle the feature flag dynamically. This fixture accepts the flag state as a parameter using request.param.<\/p>\n
\r\n@pytest.fixture(scope=\"function\")\r\ndef setup_flag(request, flag_manager, set_flag_initial_state):\r\n    \"\"\"Dynamically set feature flag states for a test.\"\"\"\r\n    flag_state = request.param\r\n    flag_manager.set_flag(\"hideAuthButtons\", flag_state)\r\n\r\n<\/pre>\n
Here, setup_flag depends on set_flag_initial_state, ensuring the flag always starts from the initial state before being toggled. The request.param allows us to pass the desired flag state from the test, making it easy to validate both states of the feature flag.<\/p>\n
4. Writing the Parameterized Test<\/h5>\n
Finally, we use pytest.mark.parametrize to define test cases for different flag states.<\/p>\n
\r\n@pytest.mark.parametrize(\"feature_flag_state\", [False, True])\r\n@pytest.mark.GUI\r\ndef test_manage_users_page(test_obj, feature_flag_state):\r\n    \"\"\"Test the manage users page with different feature flag states.\"\"\"\r\n\r\n<\/pre>\n
Here, feature_flag_state provides values for toggling the flag, enabling the test to validate both enabled and disabled states. <\/p>\n
If testers don\u2019t have direct access to control feature flags, collaboration with the development team becomes essential. Developers can help create a test environment with predefined flag states or introduce a mechanism, like environment-specific configurations, that allow testers to validate different scenarios. Alternatively, testers can simulate flag states by mocking feature flag behavior within the tests themselves, provided the application architecture supports such flexibility. This ensures that the testing process remains thorough and reliable, even without direct flag management access.<\/p>\n
\n
Handling Retired Feature Flags<\/h3>\n
When a feature flag is retired, testers need to update the test cases and clean up code related to the flag. However, it\u2019s essential to collaborate closely with developers during this process. Testers must understand the timeline for flag retirement so they can update tests before the flag is fully retired. Without this information, tests may fail as flag-dependent code paths are merged or removed.<\/p>\n
By working with developers, testers can ensure they are prepared for the transition, updating tests to align with the new, unified implementation. This collaboration minimizes disruptions and ensures the tests remain accurate and reliable throughout the process.<\/p>\n
\n
Conclusion<\/h3>\n
In summary, testing with feature flags can add complexity, but with the right strategies, it\u2019s possible to manage it efficiently. By carefully selecting and adapting testing techniques, testers can ensure they maintain clear, reliable tests, even as the number of flags grows or becomes more dynamic. Collaboration with developers plays a key role, especially when managing more complex scenarios or ensuring flag-dependent behavior is properly handled. This combination of effective strategies and collaboration ensures that feature flags don\u2019t compromise test quality, but rather enhance the flexibility of your testing process.<\/p>\n
\n
Take your testing to the next level with Qxf2<\/h3>\n
Qxf2 has been helping startups navigate complex testing challenges since 2013. Our deep expertise in testing strategies, including advanced topics like feature flags, ensures your releases are faster, safer, and more controlled. If you’re looking for a QA partner that understands the nuances of modern development workflows, explore our specialized QA services for startups<\/a>.<\/p>\n
\n","protected":false},"excerpt":{"rendered":"
Feature flags introduce a layer of dynamic behavior in applications, enabling toggled changes without redeployment. While they empower development and experimentation, they also bring unique challenges to testing. Designing tests around feature flags requires recognizing that one size does not fit all\u2014different scenarios demand different strategies. In this post, we explore a range of approaches to help maintain adaptable, and […]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[436],"tags":[],"class_list":["post-23016","post","type-post","status-publish","format-standard","hentry","category-feature-flag-tests"],"_links":{"self":[{"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/posts\/23016","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/comments?post=23016"}],"version-history":[{"count":18,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/posts\/23016\/revisions"}],"predecessor-version":[{"id":23094,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/posts\/23016\/revisions\/23094"}],"wp:attachment":[{"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/media?parent=23016"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/categories?post=23016"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/tags?post=23016"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}