test: refactor automation strategy around real APISIX E2E and Ginkgo

[guoqqqi]

Background

Current a6 test strategy still mixes two models:

• command-layer tests under pkg/cmd/** rely heavily on mocked APISIX Admin API responses
• real end-to-end coverage exists under test/e2e/, but it is still built on Go's standard testing package rather than a scenario-oriented framework

We are now adopting two new rules for the repository:

1. Command behavior tests must stop using mocked APISIX Admin API responses. If a command's behavior depends on the Admin API, it should be covered by E2E against a real APISIX instance.
2. E2E should be standardized on Ginkgo/Gomega, following the scenario-oriented style used in large integration suites such as Kubernetes e2e.

Goal

Refactor the a6 automated test strategy so that:

• unit tests are only used for pure logic that does not require mocking external environments
• command behavior coverage is migrated toward real APISIX E2E
• Ginkgo becomes the standard framework for E2E organization and execution
• CI remains stable during the migration

Deliverables

• updated testing policy and repository guidance
• Ginkgo/Gomega E2E foundation in test/e2e
• phased migration plan for command coverage from mocked Admin API tests to real E2E
• eventual cleanup of legacy mocked command tests

Execution Plan

This umbrella is tracked by the following issues:

• policy/docs update
• Ginkgo E2E bootstrap
• first migration batch for core resources
• later migration and legacy cleanup

Notes

• this issue is about strategy and phased migration, not a single implementation PR
• #14 remains the original follow-up issue that identified testing gaps; this issue narrows the next-stage testing architecture work

[guoqqqi]

Implementation plan for the new testing strategy:

1. Policy/docs phase

• Track in docs(test): redefine unit-vs-e2e policy for a6 #20
• Rewrite docs so the repository no longer recommends mocked APISIX Admin API tests for command behavior
• Define the allowed unit-test boundary: pure logic, self-contained helpers, and no external-environment mocking
• Document Ginkgo/Gomega as the standard E2E direction

2. Ginkgo E2E bootstrap phase

• Track in test(e2e): bootstrap Ginkgo/Gomega framework for real APISIX scenarios #23
• Add Ginkgo/Gomega and establish a reusable suite/framework under test/e2e
• Keep the current real APISIX/etcd/httpbin topology and environment variables
• Introduce shared helpers for binary setup, admin API access, gateway checks, Eventually-style waits, cleanup, and capability-gated skips

3. First migration batch

• Track in test: migrate core command coverage from mocked Admin API tests to real E2E #22
• Move the highest-value command coverage from mocked Admin API tests to real APISIX E2E for route, service, upstream, plugin-config, and global-rule/label/export combinations
• Ensure each migrated family has CRUD plus at least one real gateway traffic validation path
• Remove or retire the corresponding mocked command tests once equivalent E2E coverage is in place

4. Remaining migration and cleanup

• Track in test: migrate remaining resource commands and remove legacy mock-command coverage #21
• Continue with consumer, credential, consumer-group, ssl, stream-route, proto, secret, plugin-metadata, and the remaining command families where behavior still depends on mocked Admin API responses
• Preserve only pure-logic unit tests outside E2E
• Bring docs and CI to the final steady-state once the migration is complete

Execution order should be: #20 -> #23 -> #22 -> #21. The intent is to freeze the new rules first, then build the framework, then migrate in batches without a big-bang rewrite.