🧪 Lecture 16 · Quality assurance & testing

Software Testing, TDD & APIs

امتحان الشتا بتاع 2025 جاب 4 أسئلة من هنا: TDD steps, REST APIs, Black-box, White-box. لازم تعرف الـ TDD cycle والـ HTTP methods كويس جداً.

← All Lectures 🎯 جرب أسئلة الامتحان

Chapters

Rules of Bugs

TDD Laws

Exam Qs

Introduction to Testing

"Program testing can show the presence of bugs, but never their absence" — Dijkstra.

📖 Definitions

Software Testing = إنك تشغل البرنامج بغرض إنك تلاقي الـ errors اللي فيه.
هي عملية بتديك ثقة إن البرنامج بيعمل المطلوب منه بالظبط عن طريق إنك تجربه على داتا مختلفة (test data).
نشاط خاص بالـ QA هدفه إنه يلاقي الـ bugs في الكود الشغال ويصلحها.

👥 Tester vs QA Engineer

Tester: هو اللي بيكتب الـ test cases ويشغل البرنامج عشان يلاقي الـ bugs.
QA Engineer: هو اللي بيخطط للـ QA وبيحط standards وطرق عشان يمنع الـ bugs إنها تحصل من الأساس.

💡 Lion King 1994 Disasterديزني نزلت لعبة "Lion King Animated Storybook" على CD-ROM من غير ما تعملها testing على موديلات PC مختلفة. بعد الكريسماس في 1995، التليفونات مابطلتش رن من الأهالي الغضبانة. ديزني اضطرت تعين فريق دعم فني، وتعمل debug cycle تانية، وتشحن آلاف الـ CDs البديلة للناس.

Bugs — Cost & Types

Cost of bug grows exponentially as it's found later.

💰 The Cost of Bugs (Ron Patton)

Phase	Cost to Fix
Specification	$1
Design	$10
Code	$100
Test	$1,000
Release	$1,000+

Goal: تلاقي الـ bugs بدري على قد ما تقدر (عشان التكلفة متزيدش).

📜 5 Rules That Define a Bug

امتى نقول إن فيه bug؟ لو حصل حاجة أو أكتر من دول:

Rule 1: السوفتوير مبيعملش حاجة الـ spec قال إنه المفروض يعملها.
Rule 2: السوفتوير بيعمل حاجة الـ spec قال إنه المفروض ميعملهاش.
Rule 3: السوفتوير بيعمل حاجة الـ spec مجابش سيرتها خالص.
Rule 4: السوفتوير مبيعملش حاجة الـ spec مجابش سيرتها بس المفروض بديهياً تتعمل.
Rule 5: السوفتوير صعب يتفهم، رخم في استخدامه، أو بطيء... يعني مش مظبوط.

🚨 Severity (How Bad)

Critical

System crashes, security breach

Major

Wrong result, loss of functionality

Minor

Misspelling, UI layout, rare occurrence

Suggestion

Improvement idea

⏰ Priority (How Soon)

Immediate fix — لازم تتصلح فوراً لأنها بتعطل الـ testing وواضحة جداً.
لازم تتصلح قبل الـ release.
يستحسن تتصلح لما يكون فيه وقت.
يا ريت تتصلح بس ينفع ننزل بالـ release عادي من غيرها.

💡 Sev vs Priالـ Severity (الشدة) = تأثيرها عامل إزاي. الـ Priority (الأولوية) = السرعة اللي محتاجين نصلحها بيها. مثلاً: غلطة إملائية (Misspelling) خلت آلاف اليوزرز يتصلوا بالدعم الفني = دي Severity 3 بس Priority 2 (لأنها مش قاتلة بس لازم تتصلح بسرعة عشان وجع الدماغ).

Testing Levels (Stages)

4 مستويات بتبدأ من الـ unit لحد الـ acceptance.

📊 4 Levels (Bottom-Up)

Acceptance Testing — System ready for delivery?

System Testing — Whole system vs requirements

Integration Testing — Combined units interactions

Unit Testing — Individual components

Level	Purpose
Unit (UT)	Test individual components; each unit performs as designed
Integration (IT)	Test groups of units to expose interaction faults
System (ST)	Complete integrated system vs specified requirements
Acceptance (AT)	Business requirements + delivery readiness

Black-Box vs White-Box

خد بالك، امتحان الشتا بتاع 2025 سأل عن الـ Black-box equivalence partitioning.

⬛ Black-Box (Specification-based)

بيتأكد إن البرنامج ماشي مع الـ specification المكتوبة → (function coverage).
Abstraction from details: مش محتاج تشوف الـ source code أصلاً.
Scales up: بينفع مع كل المستويات (unit, integration, system, acceptance).
بيكشف الـ missing functionality (الحاجات اللي ناقصة ومش موجودة، وده الـ white-box ميعرفش يعمله).
من طرقه: Equivalence Partitioning والـ Boundary Value Analysis.

⬜ White-Box (Structural)

بيتيست على الـ implementation نفسه (الكود).
الـ tester بيكون متأكد من الـ code coverage (غطى كام سطر).
مبني على مسار الداتا والكنترول في الكود — فبيسهّل الـ debugging.
مبينفعش يكبر معاك أوي (Does NOT scale up) — بيفيد أكتر حاجة في الـ unit والـ integration.
أنواع الـ Coverage فيه: Statement, Branch, Path.
بيكشف الـ unexpected functionality (الحاجات اللي الكود بيعملها بالغلط أو زيادة).

💡 نصيحةاستخدم الاتنين مع بعض! كل واحد فيهم بيكشف أنواع مختلفة من الـ bugs.

📊 Equivalence Partitioning (BB)

بتقسم الـ inputs اللي عندك لـ مجموعتين أو أكتر:

مجموعة الـ Valid (الصح اللي المفروض يتقبل)
مجموعة الـ Invalid (الغلط اللي المفروض يترفض)

وبعدين تاخد قيمة واحدة من كل مجموعة تجرب بيها (كـ مندوب عن الباقي).

Example — Reward Points (Winter 2025 Q1.04)

Function returns reward points. If purchase ≤ 1000 LE → 10%. If > 1000 LE → 20%. If input is negative → throw exception.

Partitions:

Input ≤ 0 → exception
Input (0, 1000] → 10% reward
Input > 1000 → 20% reward

Test cases to cover all partitions:

TC1: input 100,  output 10     (10% partition)
TC2: input 1000, output 100    (10% partition — boundary)
TC3: input -100, throw exception (invalid)
// But this misses the 20% partition!

// Correct set:
TC1: 10 & M, 18 & F, 75 & F     // (Winter 2025 example)
TC2: 100 → 10,  2000 → 400,  -200 → throw

🎯 Boundary Value Analysis

أغلب الـ bugs بتبقى موجودة عند الـ boundaries (الحدود). عشان كده جرب قيمة على الحد بالظبط، وأقل منه بسنة، وأكبر منه بسنة.

مثال لو العمر من 18 لـ 65:

17, 18, 19 (الحد اللي تحت)
64, 65, 66 (الحد اللي فوق)
-1, 0, 1 (حالات خاصة عند الصفر)

Test-Driven Development (TDD) ⭐

جه في امتحان الشتا بتاع 2025 سؤال عن ترتيب الـ TDD steps.

🔄 TDD Definition

الـ TDD هو أسلوب في الشغل بنركز فيه إننا نكتب الـ unit test cases الأول قبل ما نكتب كود البرنامج نفسه.

شغالين بنظام iterative (لفات) بتجمع بين: كتابة الكود + الـ unit tests + تظبيط الكود (refactoring).

🔴🟢🔵 The TDD Cycle

🔴
1. RED
اكتب تست بيفيل

→

🟢
2. GREEN
اكتب كود يمشّي التست

→

🔵
3. REFACTOR
نضّف الكود من غير ما تكسره

📜 3 Laws of TDD (Uncle Bob)

ممنوع تكتب أي production code قبل ما تكتب تست بيفيل (failing test).
ممنوع تكتب كود في التست أكتر من اللي محتاجه عشان يفيل.
ممنوع تكتب production code أكتر من اللي محتاجه عشان تنجح التست اللي بيفيل دلوقتي.

📋 Step Order ⭐ (Winter 2025 Q1.01)

ترتيب خطوات الـ TDD الصح كالتالي (ده سؤال جه في امتحان الشتا):

اكتب تست (Write a test) (خطوة 2 في ورقة الأسئلة)
التست يفيل (Test fails) (خطوة 3)
اكتب الكود (Write code) (خطوة 5)
التست ينجح (Test passes) (خطوة 4)
نضف الكود (Refactor code) (خطوة 1)

🎯 Answer: 2 → 3 → 5 → 4 → 1 = (c) in the exam.

💻 Quick Example — abs() function

JavaScript — TDD cycle

// 🔴 Step 1: Write failing test
function testAbsoPos5() {
  return abso(5) === 5;
}

// 🟢 Step 2: Write minimal code
function abso(num) {
  return num;  // Just enough to pass
}

// 🔴 Step 3: Write new failing test
function testAbsoNeg5() {
  return abso(-5) === 5;
}

// 🟢 Step 4: Extend code to pass
function abso(num) {
  if (num < 0) return -num;
  return num;
}

// 🔵 Step 5: Refactor (if needed)

Python unittest Library

الـ standard library في بايثون عشان تعمل unit testing.

🐍 unittest Anatomy

بتعمل import unittest.
تعمل Import للكود بتاعك اللي هتعمله تست: from my_module import my_function.
تعمل كلاس للتست: class TestMyCode(unittest.TestCase).
تكتب الـ test methods بتاعتك ولازم تبدأ بكلمة test_.

import unittest
class TestSomething(unittest.TestCase):
    def test_pass(self):
        self.assertEqual(2 + 2, 4)
    def test_fail(self):
        self.assertEqual(2 + 2, 42)

if __name__ == '__main__':
    unittest.main()

✓ Common assert Methods

Method	Use
`assertEqual(a, b)`	Passes if a == b
`assertNotEqual(a, b)`	Passes if a != b
`assertTrue(x)`	Passes if x is truthy
`assertFalse(x)`	Passes if x is falsy
`assertIsNone(x)`	Passes if x is None
`assertIsNotNone(x)`	Passes if x is not None
`assertIn(a, list)`	Passes if a is in list
`assertAlmostEqual(a, b)`	For floats (handles tiny diffs)

REST APIs ⭐

Winter 2025 Q1.02: REST APIs — which is FALSE?

📡 What is a REST API?

API (Application Programming Interface) = set of rules to interact with another software.
REST (Representational State Transfer) = architectural style for web services serving data (not web pages).
Communicate over HTTP using standard methods.
Looks like a website BUT it's NOT a website. Has an endpoint.
Serves data, not web pages. Accessed by software.

🌐 HTTP Methods (CRUD)

GET

Read · retrieve data

POST

Create · new resource

PUT

Update existing

DELETE

Remove resource

Method	Example
GET /users	Fetches list of users
POST /users	Adds a new user
PUT /users/1	Updates user with ID 1
DELETE /users/1	Deletes user with ID 1

🏗️ REST Architecture

Resources: objects/data the API manipulates (users, posts).
URIs (Uniform Resource Identifiers): unique endpoint per resource (/users/1).
HTTP Methods: GET, POST, PUT, DELETE.
Stateless: each request must contain ALL information needed — no session state on server. ⭐
Responses: status codes + data in JSON or XML.

HTTP Status Codes

Code	Meaning
200 OK	Successful GET
201 Created	Successful POST
404 Not Found	Resource doesn't exist

⚠️ Winter 2025 Q1.02 — FALSE statement"They maintain state/session information from one API call to the next" is FALSE. REST is STATELESS by design — each request is independent.

💻 Python REST Example

import requests

url = "https://catfact.ninja/fact"
try:
    response = requests.get(url)
    response.raise_for_status()  # Raise on HTTP error
    data = response.json()
    print(data)
except requests.exceptions.RequestException as e:
    print(f"Error: {e}")

🎯

Exam Bank — Lecture 16

4 أسئلة من Winter 2025 + 4 practice.

Question 1 Winter 2025 · Q1.01

Given these steps for TDD, what is the correct order?
1) refactor code · 2) write a test · 3) test fails · 4) test passes · 5) write code

A 5, 1, 3, 2, 4

B 5, 3, 1, 2, 4

C 2, 3, 5, 4, 1

D 2, 3, 1, 4, 5

✅ الإجابة الصح: C — 2, 3, 5, 4, 1 تكتب test (2) → الـ test يفشل (3) → تكتب code (5) → الـ test ينجح (4) → تعمل refactor (1). دي الـ TDD cycle الكلاسيكية يا ريس.

Question 2 Winter 2025 · Q1.02

What is FALSE about REST APIs?

A They are designed as end points to access programs via other programs

B They maintain state/session information from one API call to the next

C They have a unique URI for each endpoint

D They can be implemented via HTTP requests returning JSON or XML

✅ الإجابة الصح: B الـ REST بطبيعته STATELESS. كل request لازم يكون فيه كل المعلومات المطلوبة. السيرفر مش بيحفظ أي session state.

Question 3 Winter 2025 · Q1.04

Function returns reward points: ≤1000 LE → 10%, >1000 → 20%, negative → exception. Which test cases satisfy equivalence partitioning (covering all partitions)?

A TC1: 100→10 · TC2: 1000→100 · TC3: −100→exception

B TC1: 0→0 · TC2: 100→10 · TC3: 1000→100

C TC1: 1000→100 · TC2: −200→ex · TC3: −1000→ex

D TC1: 200→20 · TC2: 2000→400 · TC3: −200→exception

✅ الإجابة الصح: D — All 3 partitions covered

200 → 20 (دي بتغطي الجزء بتاع الـ 10% للأرقام ≤1000)
2000 → 400 (دي بتغطي الجزء بتاع الـ 20% للأرقام >1000)
−200 → exception (دي بتغطي الجزء الـ invalid)

A — غطت الـ 10% والـ invalid بس، ونسيت الـ 20%. · B — مفيش حاجة للـ invalid. · C — رقمين بالسالب (نفس الـ partition)، ومفيش حاجة للـ 20%.

Question 4 Winter 2025 · Q1.03

Min test cases for: (1) FULL statement coverage, (2) FULL path coverage (not branch)?

A 2 for statement, 4 for path

B 1 for statement, 2 for path

C 2 for statement, 2 for path

D 1 for statement, 4 for path

✅ الإجابة الصح: D الـ Statement coverage = كافي 1 TC بس عشان يضرب كل الـ statements. إنما الـ Path coverage = محتاج 1 TC لكل مسار مستقل. ده فرق كلاسيكي بيجي كتير.

Question 5 Practice — bug rules

The software performs square roots but the spec doesn't mention this functionality. Is this a bug? Which rule?

A Not a bug

B Rule 1 (didn't do what spec says)

C Rule 2 (did what spec says it shouldn't)

D Rule 3 (did something spec doesn't mention)

✅ الإجابة الصح: D — Rule 3 إنك تضيف features مش متوثقة ده يعتبر bug. الـ spec هو الأساس اللي بتمشي عليه — أي حاجة زيادة بتعتبر uncontrolled scope (حاجة بره السيطرة).

Question 6 Practice — HTTP methods

To update an existing user's profile, which HTTP method?

A GET

B PUT

C POST

D DELETE

✅ الإجابة الصح: B — PUT الـ PUT بيحدث resource موجود. الـ POST بيكريت واحد جديد. الـ GET بيقرأ. والـ DELETE بيمسح.

Question 7 Practice — testing levels

Which testing level checks the system against business requirements before delivery?

A Unit Testing

B Integration Testing

C Acceptance Testing

D System Testing

✅ الإجابة الصح: C — Acceptance Testing الـ Acceptance Testing معناه "خلاص جاهز للتسليم" → فبيختبروه بناءً على الـ business requirements. أما الـ System Testing فده عشان يتأكدوا إنه مطابق للـ (technical) requirements.

Question 8 Practice — TDD law

According to Uncle Bob's TDD laws, you may NOT write production code unless:

A You have written a failing test

B You have approval from the manager

C You have refactored the existing code

D You have written documentation

✅ الإجابة الصح: A — Failing test first أول قانون في الـ TDD: متكتبش أي production code إلا لما يكون فيه test مكتوب وبيفشل.

📋

Cheat Sheet

🐛 5 Bug Rules

Rule 1

Doesn't do what spec says

Rule 2

Does what spec says it shouldn't

Rule 3

Does something spec doesn't mention

Rule 4

Doesn't do something it should (implicit)

Rule 5

Hard to use / slow / unfriendly

🔄 TDD Cycle

RED

Write a failing test

GREEN

Write minimal code to pass

REFACTOR

Clean up code, tests still pass

Order

Test → Fail → Code → Pass → Refactor

📊 Testing Levels

Unit (UT)

Individual components

Integration (IT)

Combined units

System (ST)

Whole system vs specified req

Acceptance (AT)

Business req + delivery readiness

⬛⬜ Box Testing

Black-Box

Spec-based, no code access, scales up

BB Technique

Equivalence Partitioning + Boundary Value

White-Box

Code-based, structural

WB Coverage

Statement < Branch < Path

🌐 REST API

GET

Read

POST

Create

PUT

Update

DELETE

Remove

Stateless

⭐ NO session on server

Response format

JSON or XML

📜 3 TDD Laws (Uncle Bob)

Law 1

No production code until failing test

Law 2

Test only enough to fail

Law 3

Production code only enough to pass