Sanity.io is a modern, headless Content Management System (CMS) designed to give developers and content teams complete control over how content is structured, managed, and delivered across platforms. Unlike traditional CMS platforms, Sanity separates the content layer from the presentation layer, offering greater flexibility and scalability—especially in multi-channel environments like e-commerce. It features Sanity Studio, a customizable content editor built with React, and supports real-time collaboration, allowing multiple users to work on content simultaneously. With its API-first architecture, Sanity offers robust integration through GraphQL and GROQ, making it easy to connect with popular frontend frameworks such as React, Vue, and Next.js. At the core of its infrastructure is Content Lake, a real-time datastore that enables fast, structured, and reusable content delivery across web, mobile, and other digital platforms.
Functional testing ensures that Sanity.io’s core features—like content creation, editing, publishing, and deletion—work as expected. Testers should verify that different user roles (e.g., editor, admin, viewer) can perform only their assigned actions. Key areas include checking whether live preview functionality updates in real time and whether workflows like drafting and publishing content operate smoothly. Manual testing of these flows in Sanity Studio is essential for ensuring that content management behaves as intended.
Sanity provides powerful APIs through GROQ and GraphQL, and it’s important to validate that these endpoints return accurate, filtered, and reliable content. API testing should cover operations like content fetching, filtering by parameters, creating new entries, and updating records. Testers should also check how the system handles invalid requests and whether proper error codes are returned. Tools like Postman, Insomnia, or automated scripts can help validate API stability, speed, and data integrity across multiple use cases.
Performance testing is critical when dealing with high-traffic e-commerce platforms using Sanity. Testers should simulate heavy loads to see how well Sanity Studio and the Content Lake perform when thousands of entries exist or when concurrent API calls are made. Tools such as JMeter, Artillery, or k6 can be used to measure response times, API throughput, and system behaviour under load—ensuring the CMS remains stable as the data scales.
Since content editors and marketers are key users of Sanity Studio, usability testing helps ensure that the interface is intuitive and accessible. Testers should observe whether users can easily navigate the Studio, perform tasks like editing content or updating metadata, and understand the structure without technical training. Feedback from non-technical users is especially valuable here and can highlight unnecessary friction in everyday content operations.
Security testing in Sanity is about ensuring that content, user roles, and access controls are properly enforced. This includes verifying that unauthorised users can’t access restricted content or APIs, that tokens and API keys are handled securely, and that user permissions (read, write, delete) are functioning as expected. Use vulnerability scanners, token access validation, and role-based permission testing to detect and prevent common risks like token exposure or privilege escalation.
Sanity.io supports a range of automation opportunities. Testers can automate API testing using tools like Postman with Newman or frameworks like RestAssured (Java). Since Sanity Studio is built in React, UI automation using Playwright or Cypress is also feasible. You can write scripts to automatically create, edit, and delete content, making it easier to validate workflows after schema changes, platform updates, or content migrations.
Test Case ID | Test Scenario | Steps | Expected Result |
TC-01 | Create a new document (e.g., Blog Post) | 1. Log in as Editor 2. Navigate to the Content section 3. Click “New” and fill in the required fields 4. Save as draft |
The document is saved as a draft successfully |
TC-02 | Publish a document | 1. Open the draft document 2. Click “Publish” |
Document status changes to “Published”; API reflects the change |
TC-03 | Edit an existing document | 1. Open the published document 2. Update title/content 3. Save changes |
Changes are saved and updated in real-time |
TC-04 | Validate required fields | 1. Try to create a document without filling in mandatory fields 2. Save |
The system should display appropriate error messages |
TC-05 | Validate Image insertion | 1. Log in as Editor
2. Navigate to a Content section 3. Insert image in the image section 4. Publish the changes |
The images added should be displayed in the storefront |
TC-06 | Validate Multi-Language contents | 1. Log in as Editor
2. Navigate to a Content section 3. Add multiple language content for the configurations 4. Publish the changes |
The language-specific content should be displayed when the storefront locale is changed |
TC-07 | Validate contents for multiple Countries | 1. Log in as Editor
2. Navigate to a Content section for a Country 3. Add content/ configurations for a specific page 4. Publish the changes |
The contents/configurations should be displayed for the specific country |
TC-08 | Validate references configured for category/brand | 1. Log in as Editor
2. Navigate to a Content section 3. Add category/brand references to page contents 4. Publish the changes |
The category/brand should be linked and navigated correctly |
TC-09 | API content fetch (GROQ/GraphQL) | 1. Use the API to fetch a published document | API response should return the correct and updated content |
TC-10 | Test user roles and permissions | 1. Log in as Viewer 2. Try to edit a document |
The viewer should not have edit permissions; Edit options are disabled |
TC-11 | Real-time collaboration | 1. Open the same document from two users 2. Edit from both sessions |
Changes should appear in real-time without conflicts |
TC-12 | Content preview feature | 1. Create a draft 2. Click “Preview” |
Content preview should display correctly based on the frontend integration |
TC-13 | Bulk content operations | 1. Select multiple documents 2. Perform delete/archive operation |
All selected documents should be updated accordingly |
TC-14 | Response time of the content API | 1. Send multiple concurrent API requests | API should respond within acceptable performance thresholds (e.g., <500ms) |
TC-15 | Schema validation (custom rules) | 1. Try to save invalid data (e.g., duplicate slug if it should be unique) | The system should reject invalid input and show a validation message |
TC-16 | Backup and restore simulation | 1. Simulate accidental deletion 2. Attempt recovery/rollback |
Content should be recoverable if backup systems are active |
TC-17 | Token security validation | 1. Use an invalid/expired API token 2. Try accessing the content |
Access should be denied with an appropriate error |
TC-18 | Test the mobile responsiveness of Sanity Studio | 1. Open Studio on a mobile device 2. Perform basic actions |
Studio should adapt correctly to mobile screen sizes |
TC-19 | Large dataset handling | 1. Load a dataset with 10,000+ entries 2. Test search, pagination |
Studio should remain performant and responsive |