Add use-case based acceptance tests for Schema resource (#298)

* Use-case based acceptance tests for Schema resource * Keep scenario names consistent
redpanda-data · Nov 12, 2024 · c97d279 · c97d279
1 parent 3a34a83
commit c97d279
Show file tree

Hide file tree

Showing 3 changed files with 113 additions and 30 deletions.
diff --git a/acceptance/README.md b/acceptance/README.md
@@ -2,11 +2,27 @@
 
 ## Feature testing map
 <!-- insert snippet -->
+### Feature: Schema CRDs
+
+|                 SCENARIO                 | EKS | AKS | GKE | K3D |
+|------------------------------------------|-----|-----|-----|-----|
+| Manage product catalog schema (Protobuf) |     |     |     | ✅  |
+| Manage order event schema (JSON)         |     |     |     | ✅  |
+| Manage customer profile schema (Avro)    |     |     |     | ✅  |
+
+
+### Feature: Topic CRDs
+
+|   SCENARIO    | EKS | AKS | GKE | K3D |
+|---------------|-----|-----|-----|-----|
+| Manage topics |     |     |     | ✅  |
+
+
 ### Feature: User CRDs
 
-|              SCENARIO              | EKS | AKS | GKE | K3D |
-|------------------------------------|-----|-----|-----|-----|
-| Managing Users                     |     |     |     | ✅  |
-| Managing Authentication-only Users |     |     |     | ✅  |
-| Managing Authorization-only Users  |     |     |     | ✅  |
+|             SCENARIO             | EKS | AKS | GKE | K3D |
+|----------------------------------|-----|-----|-----|-----|
+| Manage users                     |     |     |     | ✅  |
+| Manage authentication-only users |     |     |     | ✅  |
+| Manage authorization-only users  |     |     |     | ✅  |
 
diff --git a/acceptance/features/schema-crds.feature b/acceptance/features/schema-crds.feature
@@ -4,35 +4,102 @@ Feature: Schema CRDs
     Given cluster "basic" is available
 
   @skip:gke @skip:aks @skip:eks
-  Scenario: Managing Schemas
-    Given there is no schema "schema1" in cluster "basic"
+  Scenario: Manage customer profile schema (Avro)
+    Given there is no schema "customer-profile" in cluster "basic"
     When I apply Kubernetes manifest:
     """
+    # tag::customer-profile-avro-schema-manifest[]
+    # This manifest creates an Avro schema named "customer-profile" in the "basic" cluster.
+    # The schema defines a record with fields for customer ID, name, and age.
     ---
     apiVersion: cluster.redpanda.com/v1alpha2
     kind: Schema
     metadata:
-        name: schema1
+      name: customer-profile
     spec:
-        cluster:
-            clusterRef:
-                name: basic
-        text: |
-            {
-                "type": "record",
-                "name": "test",
-                "fields":
-                [
-                    {
-                        "type": "string",
-                        "name": "field1"
-                    },
-                    {
-                        "type": "int",
-                        "name": "field2"
-                    }
-                ]
-            }
+      cluster:
+        clusterRef:
+          name: basic
+      schemaType: avro
+      compatibilityLevel: Backward
+      text: |
+        {
+          "type": "record",
+          "name": "CustomerProfile",
+          "fields": [
+            { "type": "string", "name": "customer_id" },
+            { "type": "string", "name": "name" },
+            { "type": "int", "name": "age" }
+          ]
+        }
+    # end::customer-profile-avro-schema-manifest[]
     """
-    And schema "schema1" is successfully synced
-    Then I should be able to check compatibility against "schema1" in cluster "basic"
+    And schema "customer-profile" is successfully synced
+    Then I should be able to check compatibility against "customer-profile" in cluster "basic"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage product catalog schema (Protobuf)
+    Given there is no schema "product-catalog" in cluster "basic"
+    When I apply Kubernetes manifest:
+    """
+    # tag::product-catalog-protobuf-schema-manifest[]
+    # This manifest creates a Protobuf schema named "product-catalog" in the "basic" cluster.
+    # The schema defines a message "Product" with fields for product ID, name, price, and category.
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Schema
+    metadata:
+      name: product-catalog
+    spec:
+      cluster:
+        clusterRef:
+          name: basic
+      schemaType: protobuf
+      compatibilityLevel: Backward
+      text: |
+        syntax = "proto3";
+
+        message Product {
+          int32 product_id = 1;
+          string product_name = 2;
+          double price = 3;
+          string category = 4;
+        }
+    # end::product-catalog-protobuf-schema-manifest[]
+    """
+    And schema "product-catalog" is successfully synced
+    Then I should be able to check compatibility against "product-catalog" in cluster "basic"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage order event schema (JSON)
+    Given there is no schema "order-event" in cluster "basic"
+    When I apply Kubernetes manifest:
+    """
+    # tag::order-event-json-schema-manifest[]
+    # This manifest creates a JSON schema named "order-event" in the "basic" cluster.
+    # The schema requires an "order_id" (string) and a "total" (number) field, with no additional properties allowed.
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Schema
+    metadata:
+      name: order-event
+    spec:
+      cluster:
+        clusterRef:
+          name: basic
+      compatibilityLevel: None
+      text: |
+        {
+          "$schema": "http://json-schema.org/draft-07/schema#",
+          "type": "object",
+          "properties": {
+            "order_id": { "type": "string" },
+            "total": { "type": "number" }
+          },
+          "required": ["order_id", "total"],
+          "additionalProperties": false
+        }
+    # end::order-event-json-schema-manifest[]
+    """
+    And schema "order-event" is successfully synced
+    Then I should be able to check compatibility against "order-event" in cluster "basic"
diff --git a/acceptance/features/topic-crds.feature b/acceptance/features/topic-crds.feature
@@ -4,7 +4,7 @@ Feature: Topic CRDs
     Given cluster "basic" is available
 
   @skip:gke @skip:aks @skip:eks
-  Scenario: Managing Topics
+  Scenario: Manage topics
     Given there is no topic "topic1" in cluster "basic"
     When I apply Kubernetes manifest:
     """