Lesson 4 / الدرس 4

Testing without a page / الاختبار بلا صفحة

Behind most screens is a service that answers questions directly. Talking to it removes the browser, the layout and the waiting from your test — and lets you ask things the interface will not let you ask.

خلف معظم الشاشات خدمةٌ تجيب عن الأسئلة مباشرة. ومخاطبتها تزيل من اختبارك المتصفحَ والتخطيطَ والانتظار — وتتيح لك أن تسأل ما لا تدعك الواجهة تسأله.

When you press Sign in, the page sends a request to a server and does something with the answer. You can send that request yourself. No browser, no clicking, no waiting for fonts — just the question and the answer, in a fraction of a second. Everything the engineering course taught you about HTTP is the working knowledge this needs.

What you gain by dropping the page

Speed. Hundreds of cases in the time one browser test takes to load a page once.
Certainty about what failed. A wrong status code is the service being wrong. There is no layout, no timing and no font to blame.
Questions the interface refuses. The page will not let you order -1 items or set a delivery date in 1970. The service will let you try — and what it does then is a real and important answer.
Independence from the front end. You can test the service the week before the screen that uses it is built.

What an API test looks at

Check	Example
The status code	200 for success, 401 for not signed in, 404 for missing, 422 for invalid
The body	The fields you expect, with the types you expect
What is NOT there	No password hash, no other user's data, no internal error text
The effect	After a POST, does a GET show the new thing?
The time	Did it answer within a reasonable limit?

The third row is the one testers forget and the one that matters most. An endpoint that returns the right thing plus a field it should never expose has passed every check except the one that mattered.

// The same sign-in check as before, without a browser.
const res = await fetch('https://api.example.com/sign-in', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ email: 'sara@example.com', password: 'totallywrong' })
});

expect(res.status).toBe(401);

const body = await res.json();
expect(body.message).toBe('Email or password is incorrect');
expect(body.token).toBeUndefined();      // nothing was handed out
expect(JSON.stringify(body)).not.toContain('hash');  // and nothing leaked

Four assertions, and the last two are the interesting ones. A service that returns 401 and still includes a token, or an internal field, has failed in a way no amount of clicking through the page would ever have shown you.

Check yourself / اختبر نفسك

1. What can an API test ask that a browser test usually cannot?

2. Which check do testers most often forget on an API response?

3. Why is testing an API against production more dangerous than using the website?