Phase 2- Compute

[jenniferoko]

Phase 2 — Compute

Jennifer's deliverable: Review the 12 compute test specs below. Walk the engineer through the
create → operate → delete lifecycle. Explain what each negative test (tests 14, 15, 17) is
checking and why the error code matters, not just the fact of failure.

Engineer builds: 03-compute.spec.ts (tests 11–22)

Gate: All 22 tests pass (Phase 1 + Phase 2). Cleanup is verified: after the run, no
smoke-vm-* resources remain in the test project.

---

Compute — 03-compute.spec.ts — tags: @compute @smoke

The spec creates smoke-vm-01 in beforeAll, runs all operation tests against it, then deletes
it in afterAll. Tests 14, 15, 17 are negative tests — they must return an error, not a 200.

# | Test name | Method | Endpoint | Pass condition -- | -- | -- | -- | -- 11 | list all VMs | GET | /virtual-machines | HTTP 200, array 12 | list VMs filtered by project | GET | /virtual-machines?project=smoke-tests | HTTP 200, array 13 | create VM with valid payload | POST | /virtual-machines | HTTP 200/201, data.slug present, data.state present 14 | create VM missing required field | POST | /virtual-machines (no name) | HTTP 400/422, status=Error 15 | create VM with duplicate name | POST | /virtual-machines (name already exists) | HTTP 409/422, status=Error 16 | get VM by slug | GET | /virtual-machines/smoke-vm-01 | HTTP 200, data.slug=smoke-vm-01 17 | get VM with unknown slug | GET | /virtual-machines/does-not-exist | HTTP 404, status=Error 18 | stop VM | PUT | /virtual-machines/smoke-vm-01/stop | HTTP 200, status=Success 19 | start VM | PUT | /virtual-machines/smoke-vm-01/start | HTTP 200, status=Success 20 | reboot VM | PUT | /virtual-machines/smoke-vm-01/reboot | HTTP 200, status=Success 21 | get VM console URL | GET | /virtual-machines/smoke-vm-01/console | HTTP 200, data.url is a non-empty string 22 | delete VM | DELETE | /virtual-machines/smoke-vm-01 | HTTP 200/204, status=Success

Note on lifecycle order: Tests 18–20 (stop → start → reboot) are order-dependent within this
spec. Run them sequentially, not in parallel. The VM must be running before stop, stopped before
start, running before reboot.

[jenniferoko]

Please review - Full Documentation Guide: Phase_2_Compute_Smoke_Test_Implementation_Guide.docx

Workable: QA_Post_Patch_Checklist_Tests_1-22.xlsx

Below is a professional Phase 2 implementation guide that Jennifer can use to review with the engineer before development begins.

Phase 2 – Compute Smoke Tests

Objective

Build 03-compute.spec.ts containing Compute smoke tests 11–22.

The goal is to validate the complete lifecycle of a Virtual Machine:

Create → Read → Operate → Delete

The suite should prove that Compute APIs not only work during normal operations, but also correctly reject invalid requests.

---

Compute Resource Lifecycle

The spec should use one VM throughout the test suite.

beforeAll
    │
    ├── Create smoke-vm-01
    │
Tests
    │
    ├── List VMs
    ├── Filter VMs
    ├── Create validations
    ├── Retrieve VM
    ├── Stop
    ├── Start
    ├── Reboot
    ├── Console URL
    │
afterAll
    │
    └── Delete smoke-vm-01

Using one shared VM:

• makes the suite faster

• reduces API calls

• avoids unnecessary provisioning

• simplifies cleanup

---

Test Walkthrough

Test 11 — List all VMs

Endpoint

GET /virtual-machines

Purpose

Verify Compute service is reachable and returns the VM inventory.

Expected

• HTTP 200

• response is an array

Example assertions

status === 200
Array.isArray(data)

---

Test 12 — Filter VMs by project

Endpoint

GET /virtual-machines?project=smoke-tests

Purpose

Verify filtering works correctly.

Instead of returning every VM, only VMs belonging to the smoke test project should appear.

Expected:

• HTTP 200

• array returned

---

Test 13 — Create VM

POST /virtual-machines

Purpose

Verify a VM can be provisioned successfully.

Expected:

• HTTP 200 or 201

• slug exists

• state exists

Example

{

slug: "smoke-vm-01",

state: "running"

}

---

Negative Test 14

Create VM Missing Required Field

Request

POST /virtual-machines

Payload intentionally omits

name

Example

{

project: "smoke-tests"

}

What is this testing?

The API must validate required fields.

If required data is missing, the server should reject the request.

Expected

HTTP 400

or

HTTP 422

and

status = Error

Why the error code matters

A failed request alone is not enough.

If the API returns

500 Internal Server Error

that indicates the backend crashed.

If it returns

200 OK

it accepted invalid data.

Neither behavior is correct.

A proper validation error proves

• validation rules executed

• API remained healthy

• client submitted bad input

This is exactly what should happen.

---

Negative Test 15

Create Duplicate VM

Request

Create another VM using

smoke-vm-01

again.

Purpose

Ensure uniqueness rules are enforced.

Duplicate VM names should never be created.

Expected

409 Conflict

or

422 Validation Error

with

status = Error

Why the error code matters

409 tells the client:

"The request is valid, but the resource already exists."

Returning

500

would indicate a server defect.

Returning

200

would allow duplicate infrastructure resources.

Both are incorrect.

---

Test 16 — Get VM

GET /virtual-machines/smoke-vm-01

Verify

• HTTP 200

• slug equals

smoke-vm-01

---

Negative Test 17

Unknown VM

GET /virtual-machines/does-not-exist

Purpose

Verify the API handles missing resources correctly.

Expected

404 Not Found

and

status = Error

Why the error code matters

404 communicates

"The requested resource does not exist."

It is a normal business condition.

Returning

500

would incorrectly imply the server failed.

Returning

200

would falsely claim the VM exists.

404 confirms correct API behavior.

---

Test 18 — Stop VM

PUT /virtual-machines/smoke-vm-01/stop

Expected

HTTP 200

status = Success

VM state should become stopped.

---

Test 19 — Start VM

PUT /virtual-machines/smoke-vm-01/start

Expected

HTTP 200

status = Success

VM returns to Running.

---

Test 20 — Reboot VM

PUT /virtual-machines/smoke-vm-01/reboot

Expected

HTTP 200

status = Success

---

Why Tests 18–20 Must Be Sequential

These tests depend on VM state.

Correct order:

Running

│

Stop

│

Stopped

│

Start

│

Running

│

Reboot

│

Running

Running them in parallel could produce:

• reboot while stopping

• start before stop completes

• race conditions

• intermittent failures

The suite should execute these operations serially.

---

Test 21 — Console URL

GET /virtual-machines/smoke-vm-01/console

Verify

• HTTP 200

• URL exists

• URL is a non-empty string

The test does not need to launch the console.

It only verifies that the API successfully generates an access URL.

---

Test 22 — Delete VM

DELETE /virtual-machines/smoke-vm-01

Expected

HTTP 200

or

HTTP 204

status = Success

Deletion should complete without leaving orphaned resources.

---

Cleanup Verification

After the test suite finishes:

• afterAll must delete smoke-vm-01.

• Verify there are no remaining resources matching smoke-vm-* in the test project.

• Cleanup must succeed even if earlier tests fail (for example, by using try/finally or robust teardown logic).

---

Phase 2 Acceptance Gate

The phase is considered complete only when all of the following are true:

Requirement	Expected Result
Tests implemented	03-compute.spec.ts contains tests 11–22
Lifecycle validated	Create → Operate → Delete completes successfully
Negative tests	Tests 14, 15, and 17 return the correct HTTP error codes (400/422, 409/422, and 404 respectively) with status = Error
Operation sequence	Stop → Start → Reboot executes sequentially without race conditions
Phase regression	All Phase 1 and Phase 2 tests (1–22) pass
Cleanup	No smoke-vm-* resources remain after execution

This review ensures the engineer understands not only how to implement the tests, but also why specific HTTP status codes are essential: they distinguish expected client-side validation and resource errors from genuine server failures, making the smoke suite a reliable indicator of API correctness.

[godsonten]

Your compute guide is much strong, but I would not approve it yet because there are still a few QA blockers.

Main Blockers

1. Your checklist conflicts with the epic for Phase 1.

The Excel file lists Phase 1 tests as:

• POST /auth/login
• GET /
• GET /health
• GET /version
• POST /logout

That does not match the approved epic. Phase 1 is supposed to cover:

• GET /regions
• missing token rejection
• malformed token rejection
• envelope contract
• GET /virtual-machines
• discovery endpoints 6-10

This is a sign-off risk. The checklist must match the epic exactly, otherwise QA may pass the wrong suite.

2. The VM creation flow is still ambiguous.

You say beforeAll creates smoke-vm-01, but Test 13 is also "Create VM." That creates confusion.

Pick one approach. My recommendation:

• beforeAll should only prepare fixtures and resolve payload values.
• Test 13 should create smoke-vm-01.
• Immediately after Test 13 succeeds, register the VM for cleanup.
• afterAll should delete it if it still exists.

If you keep creation in beforeAll, then Test 13 is not really a create test anymore. It becomes a setup step hidden outside the test report.

3. Serial execution must be explicit.

You correctly explain that stop, start, and reboot must run in order. Now make that an implementation requirement:

test.describe.configure({ mode: 'serial' });

This should apply to the compute lifecycle block. Do not rely on convention.

4. VM readiness is missing.

VM creation may return before the VM is fully ready for stop, console, reboot, or start operations. Add a requirement to poll the VM after creation until it reaches an operable state, likely Running, before tests 18-21 run.

Without this, the test can become flaky.

5. Delete assertion needs correction.

For Test 22, if the API returns 204, there may be no JSON body. Do not require status=Success for 204.

Use:

• 200 with status=Success
• or 204 with no body required

6. Payload details are still missing.

The engineer needs exact payload fields or a clear fixture strategy. From the API docs, VM creation likely needs values like:

• name
• project
• region
• boot_source
• template
• plan
• network_type
• networks
• is_public
• billing_cycle
• hostname

State whether these come from Phase 1 discovery endpoints, environment variables, or fixed smoke-test fixtures.

Good Parts

Your explanations for negative tests 14, 15, and 17 are good. You correctly explain why 400/422, 409/422, and 404 matter, and why 200 or 500 would be incorrect.

The console URL test is also correctly scoped. The smoke test should verify URL generation only, not launch a browser.

Final QA Recommendation

Revise Phase 2 before engineering starts.

Required changes

• Fix the Excel checklist so tests 1-22 match the epic.
• Remove the beforeAll vs Test 13 create ambiguity.
• Require serial execution.
• Add VM readiness polling.
• Correct the 204 delete assertion.
• Define the VM payload source.
• Keep cleanup verification for no smoke-vm-* resources.

After those changes, I would approve Phase 2 for engineering implementation.