Skip to content
CodeKruPro

Check a rejected change leaves saved data intact

Automation taskMedium

A strong negative test checks two things: the error response, and that the stored data did not change. Interviewers notice when you mention the second one. This lesson practises both.

Check a rejected change leaves saved data intact

04 · Design cases and verify stored changes

Recommended first: Test normalized duplicates and real deletion

Your goal: Check a rejected change leaves saved data intact

Continue one saved customer through the named test cases.

  1. 1Set up data
  2. 2Send requests
  3. 3Submit answers

Start here: sign in to practise.

Jump to practice

What you will learn

Continue the saved-customer workflow from create/read-back. This lesson uses its own workspace, so obtain fresh tokens and IDs. A mutation response and a later read are separate pieces of evidence.

Your goals

  • Build a request from the rule rather than copying an answer.
  • Keep observed evidence separate from the expected result.

Before you start

Read the previous lesson first if you have not already. This course does not require programming.

Practice setup

Click Create workspace. Then log in as the fictional customer named in the steps. Use that practice token, not your CodeKru sign-in. Reset starts this lesson’s data over and invalidates its tokens.

Follow these steps

  1. Create the workspace, log in as A and create the supplied customer. Select it and copy its id. Read and select that exact record as your before-state.
  2. PATCH that id with {"name":"Should not save","age":17}. Name is valid, but age breaks the documented 18–120 integer rule. Select the response.
  3. Read the same id as A again and select it. Compare id, name, email, age, city and owner with the before-state. An error status alone does not prove atomic rejection.
  4. Record the unchanged-state conclusion and submit before resetting. After completing the lesson, optionally Reset workspace, log in again and observe that old tokens and selected evidence cannot be reused.

Investigate before concluding

First record the actual result for each case. Compare the body, headers and later state with the stated contract. Keep an observation separate from a prediction; use the model answer only after making your own attempt.

What to keep as evidence

  • Each selected response belongs to its named case.
  • Conclusions follow the request and response evidence.
  • Another learner can repeat the work using the stated setup.
References for this lesson

Finish this assignment

Answer from the transcript on this page. Click Submit Answers. Your score is the percentage of checks that passed. A saved 100/100 means every check passed. Continue opens the next lesson you can submit.

If something goes wrong
  • Change one part of the request at a time.
  • A 401 means the practice login token is missing or expired. Log in again in this workspace.
  • A 409 on create means that fictional email is already used. Choose another email.
Self-review and independent variation
  • Each selected response belongs to its named case.
  • Conclusions follow the request and response evidence.
  • Another learner can repeat the work using the stated setup.

Explain the difference between deleting one record and resetting the entire lesson workspace.

Automatic checks verify the requests and answers configured for this lesson. The self-review is for your own reasoning. A score is not a certificate.

Open API reference

Practise and save your evidence

The lesson is public. Sign in to send requests and save progress. You will return to this lesson.

Sign in to practiseCreate an account