Software
Testing ka
pura khel.

Yeh foundation lecture hai. Isme jitne bhi terms aate hain (test case, test suite, levels), wo poore week me baar-baar use honge — isliye yahan thoda dhyaan se.

Testing kyun important hai?

Software me chhoti si error bhi pura system crash kara sakti hai. Lecture me do classic examples diye gaye:

• Integer overflow jaisi simple si galti se poore system ka crash.
• Real-world failures — airport system failure aur spacecraft crash. Inme crore-crore ka nuksaan hua sirf bugs ki wajah se.

Matlab: testing "optional extra" nahi hai, development ka core part hai.

Testing me hum basically karte kya hain?

Socho tumne koi assignment ka program submit kiya. Tumne kya kiya tha? Yehi 7 steps:

Test Case = Triplet [I, S, R]

Yeh sabse zyada poocha jaane wala definition hai. Ek test case sirf "input" nahi hota — teen cheezein hoti hain:

Test Suite = ek given program ko test karne ke liye design kiye gaye saare test cases ka set. Yaani test case = 1 unit, test suite = collection.

Testing activities ka summary

1. Test suite design — appropriate test cases socho aur banao.
2. Run test cases & check results — har test case chalao, expected vs actual compare karo. Mismatch = failure, note kar lo.
3. Locate error — jo test fail hua, developer usko dekh kar error dhoondta hai.
4. Error correction — code fix karo, phir se test karo.

Note: yeh kaam tester karta hai aur developer ko report karta hai — par bahut baar tester aur developer same hi banda hota hai.

Test cases "design" kyun karein? Random ya exhaustive kyun nahi?

Do sawaal aate hain, dono ka jawab lecture me hai:

❌ Random testing kaafi nahi hai

Bahut saare random values daal dene se guarantee nahi milti ki zyadatar errors pakde jaayenge. Classic example:

# Sahi program — min of two values
if (x < y): min = x
else:      min = y

# Buggy program — else me bhi x hai!
if (x < y): min = x
else:      min = x   <-- BUG

Agar tumhare random values me hamesha x < y hi nikla — jaise (1,2), (3,4), (1000,10000) — to ye bug kabhi pakda hi nahi jaayega. Bug tab pakdega jab koi aisi value aaye jahan y < x ho. Aur wo shayad tab pata chale jab software production me chal raha ho. 😬

❌ Exhaustive testing possible nahi hai

Kisi bhi software system me input values ka domain bahut bada hota hai — saari possible values test karna practically impossible.

✅ Isliye: minimal test suite design karo

Aisa minimal test suite banao jisme har test case ka ek specific kaam ho — har test case ek particular type ki error pakadne ke liye designed ho. Kam test cases, par har ek meaningful.

Test case design ke 2 raste

Testing ke different levels

Yeh pura week isi ladder par chalta hai — neeche se upar:

Sabse pehla level. Individual functions/units ko alag-alag test karna. Yahan pytest ka pura practical demo bhi hai — yeh programming assignment me directly kaam aata hai.

Unit testing kyun? Seedha integrate karke ek baar me test kyun nahi?

Yeh reflection spot ka sawaal hai. Do solid reasons:

Unit testing: Kab, Kaun, Kya

Testing Environment: Stub aur Driver

Problem samjho: mera module function_1(), function_2(), function_3() ko call karta hai — par wo abhi bane hi nahi hain (koi aur developer bana raha hai). Upar se mere module ko kuch non-local / global data bhi chahiye jo abhi available nahi hai. To test kaise karein? Answer: stub aur driver bana lo.

Python me unit testing tools

Do popular tools:

• unittest — Python ki built-in standard library testing ke liye.
• pytest — bahut popular tool, boilerplate code kam karta hai. Course me yahi use hota hai.

pytest ka pura walkthrough

Lecture me seller portal ka example liya gaya. Setup ye hai:

# product.py
class Product:      # product add karna, details dekhna
    ...

# inventory.py
class SellerInventory:
    # seller_inventory_map = dictionary {product_id : num_items}
    def add_items_to_inventory(self, product, num): ...
    def delete_items_from_inventory(self, product, num):
        # agar delete karne wale items zyada hain to ValueError raise
        ...
    def get_total_items(self):
        pass   # ABHI IMPLEMENT NAHI HUA — koi aur developer bana raha hai

Step 1 — Install aur naming rules

$ pip install pytest
$ pytest          # folder me tests dhoondhta hai

Step 2 — Pehla simple test (assert)

# test_seller_portal.py
def double(n):          # normal function (test_ nahi hai)
    return n * 2

def test_double():      # yeh TEST CASE hai
    assert double(10) == 20

Test case likhne ka core keyword: assert. Agar condition True → pass, False → fail.

Step 3 — Actual class ko test karna

from product import Product
from inventory import SellerInventory

def test_add_new_item_to_inventory():
    inventory = SellerInventory("S1")
    inventory.add_items_to_inventory(P1, 10)
    assert inventory.seller_inventory_map[P1] == 10

def test_add_previously_added_item_to_inventory():
    inventory = SellerInventory("S1")
    inventory.add_items_to_inventory(P1, 10)
    inventory.add_items_to_inventory(P1, 10)
    assert inventory.seller_inventory_map[P1] == 20   # update hona chahiye, replace nahi

Lecture me deliberately bug dala gaya (+ hata diya) — tab pytest ne AssertionError: 10 != 20 diya. Matlab function replace kar raha tha, add nahi. Fix karke dobara run kiya → pass. Yehi to testing ka point hai.

Good practice: test method ka naam hi bata de ki wo kya test kar raha hai — test_add_previously_added_item_to_inventory jaisa descriptive naam.

Step 4 — Fixtures (repeated setup hatane ke liye)

Problem: har test me inventory = SellerInventory("S1") baar-baar likhna pad raha hai. Solution = fixture.

import pytest

@pytest.fixture
def inventory():
    return SellerInventory("S1")     # initialization ek hi jagah

def test_add_new_item(inventory):     # fixture ko parameter ki tarah pass karo
    inventory.add_items_to_inventory(P1, 10)
    assert inventory.seller_inventory_map[P1] == 10

Fixture kya karta hai: aisi cheezein initialize/create karta hai jo saare test cases me chahiye hoti hain.

Step 5 — Exceptions test karna

Agar delete karne wale items inventory se zyada hain, to code ValueError raise karta hai. Isko test karne ke liye pytest.raises:

def test_delete_more_items_than_available(inventory):
    inventory.add_items_to_inventory(P1, 10)
    with pytest.raises(ValueError):
        inventory.delete_items_from_inventory(P1, 20)   # 20 > 10 → error aana chahiye

Lecture me ek important observation: agar 20 ki jagah 5 likh dete (10 > 5, koi error nahi), to ye test fail hota — kyunki expected exception raise hi nahi hua. Yani test sahi kaam kar raha hai.

Step 6 — Stub / Mock banana (sabse important part)

Problem: get_total_items() abhi implement nahi hua (dusra developer bana raha hai). Test chalao to None != 30 aata hai — fail. Ab kya karein? Stub bana lo — ek mock/dummy method jo us functionality ko mimic kare.

def mock_get_total_items(inventory):     # <-- yeh hamara STUB hai
    total = 0
    for pid, num in inventory.seller_inventory_map.items():
        total += num
    return total

def test_get_total_items(inventory, mocker):
    inventory.add_items_to_inventory(P1, 10)
    inventory.add_items_to_inventory(P2, 20)

    # asli get_total_items ki jagah hamara mock chalega
    inventory.get_total_items = mocker.Mock(side_effect=mock_get_total_items)

    assert inventory.get_total_items(inventory) == 30   # PASS ✓

Unit testing summary — pytest checklist

Unit testing "kya" karna hai bataata hai. Blackbox/Whitebox bataate hain ki test cases design kaise karne hain. Numerical-type questions yahin se aate hain.

Part A — Blackbox Testing (Functional Testing)

Program ek black box hai. Code ka design ya structure ka koi knowledge nahi chahiye. Sirf input–output value pairs examine karke test cases banate hain.

1. Equivalence Classes

Input values ke poore domain ko aise classes/partitions me baant do ki ek class ke har input par program same behave kare. Phir har class se sirf ek representative value uthao — poori class test ho gayi.

2. Boundary Value Analysis (BVA)

Programmers ki sabse common galti: boundaries par gadbad. < lagau ya <=? range(n) likhu ya range(n-1)? Isliye equivalence classes ke boundaries ki values se test cases banate hain.

• isPrime(num) ke liye boundary values → 0 aur 1 check karo.
• Loop ranges, array indices, "<" vs "<=" — yahi jagah bugs milte hain.

Blackbox testing ka 4-step recipe

1. Requirements/specifications se input aur output structures/values identify karo.
2. Equivalence classes identify karo.
3. Har equivalence class se ek representative test case design karo.
4. Boundary value test cases design karo.

Part B — Whitebox Testing (Structural Testing)

Ab code dikh raha hai. Program ka structure analyse karte hain kuch heuristics se — aur main heuristic hai coverage: kya hum program ke saare (ya almost saare) parts execute kar paa rahe hain?

Yeh pura section isi ek program par based hai:

1  def isPrime(num):
2      if num == 0 or num == 1:
3          return False
4      for n in range(2, num):
5          if num % n == 0:
6              return False
7      return True

Coverage-based testing ke 3 types:

1️⃣ Branch Coverage

Program ka har branch kam se kam ek baar execute hona chahiye. Yaani har branch condition ko ek baar True aur ek baar False banana hai.

min example: if (x<y) min=x else min=y

• Test case 1: x < y → condition True
• Test case 2: x ≥ y → condition False

isPrime ke liye (Reflection Spot ka answer):

Answer: Test cases = {0, 2, 3, 4}

2️⃣ Multiple Condition Coverage (MCC)

Jab condition composite ho (or / and se judi ho), tab har component condition ko alag-alag True aur False banana hai.

isPrime me: num == 0 or num == 1 → components hain num==0 aur num==1. Test cases {0, 1} multiple condition coverage achieve karte hain.

Ab wo example jisse branch vs MCC ka farak clear hota hai:

if (num < 50 || num > 150)
    doSomething();
else
    doSomethingElse();

3️⃣ Path Coverage

Ek test suite path coverage achieve karta hai agar wo program ke saare linearly independent paths ko kam se kam ek baar access kar le. Paths dhoondhne ke liye banate hain Control Flow Graph (CFG).

CFG kaise banta hai: har line number ka ek node, aur agar control ek line se doosri line par ja sakta hai to un dono ke beech ek edge.

Cyclomatic Complexity — kitne paths honge?

Blackbox vs Whitebox — ek nazar me

Units test ho gaye. Ab unhe jodna hai — aur jodte waqt jo naye bugs paida hote hain unhe pakadna hai. Yeh section MCQ ke liye goldmine hai.

Integration Testing

Integration ke 4 approaches — interactive

Setup: M1 top par hai aur M2, M3, M4 ko call karta hai. M5 sabse neeche hai. Button dabao aur dekho kaunsa approach kis order me integrate karta hai.

System Testing

Ab poora integrated system test hota hai. Pehle kaun test kar raha hai ke hisaab se 3 types:

System testing ke aur types

Ab tak jitna padha — sab me code pehle likha, test baad me. TDD ye ulta kar deta hai. Agile processes me specially use hota hai.

TDD ka core idea

• Functionality implement karne se pehle uska test likho.
• Design aur development ko tests se drive karo.
• Iteratively chalo: test likho → functionality banao → agla test likho → agli sub-functionality banao → …
• Saari activities chhote-chhote features verify karne ke around organise hoti hain.

RED → GREEN → REFACTOR (TDD ka mantra)

TDD ke steps (slide-wise)

1. Functionality/feature/requirement ko test ke form me express karo.
2. Test create karo, run karo — FAIL hote dekho.
3. Test ki need pura karne ke liye minimum code likho. (Pura feature nahi — sirf itna jitna test pass karne ke liye chahiye.)
4. Run karo — PASS hote dekho.
5. REFACTOR karo — code ki quality sudharo, modular banao, elegant banao, achhi coding practices lagao. Refactor ke baad bhi test pass hona chahiye.
6. Agli sub-functionality ke liye poora cycle dohrao.

Live example: TDD se isPrime() banana

Lecture me step-by-step yehi build kiya gaya. Dhyan do ki code har baar test ke reaction me badal raha hai:

# test_isprime.py — RED
from isprime import isPrime
def test_number_is_not_prime():
    assert isPrime(4) == False
# pytest chalao → FAIL (function khaali hai)

# isprime.py — GREEN (minimum code)
def isPrime(num):
    for i in range(2, num):
        if num % i == 0:
            return False
# pytest chalao → PASS ✓

# RED
def test_number_is_prime():
    assert isPrime(5) == True       # FAIL — abhi True return hi nahi hota

# GREEN
def isPrime(num):
    for i in range(2, num):
        if num % i == 0:
            return False
    return True                     # naya line

def test_two_is_prime():   assert isPrime(2) == True   # pehle se PASS ✓
def test_one_not_prime():  assert isPrime(1) == False  # FAIL ✗
def test_zero_not_prime(): assert isPrime(0) == False  # FAIL ✗

# GREEN — 0 aur 1 handle karo
def isPrime(num):
    if num == 0 or num == 1:
        return False
    for i in range(2, num):
        if num % i == 0:
            return False
    return True          # ✓ ab saare test pass

TDD vs Normal Testing

Exam se 15 minute pehle sirf yeh padh lena kaafi hai.

Poora week ek diagram me

SOFTWARE TESTING
│
├── Terminology ── Test Case [I,S,R] → Test Suite
│
├── LEVELS
│   ├── Unit Testing ──── Stub + Driver ── pytest
│   │      └── Test case design kaise?
│   │            ├── BLACKBOX ── Equivalence Classes + Boundary Value Analysis
│   │            └── WHITEBOX ── Branch / Multiple Condition / Path coverage
│   │                              └── Cyclomatic Complexity = D + L + 1
│   │
│   ├── Integration Testing ── Big Bang | Bottom-Up | Top-Down | Mixed
│   │                            (interface errors pakadna)
│   │
│   ├── System Testing ── Alpha | Beta | Smoke | Performance (Stress)
│   │
│   └── Acceptance Testing ── customer decides
│
└── PROCESS ── TDD: RED → GREEN → REFACTOR

Option par click karo — turant pata chal jaayega sahi hai ya galat, aur neeche explanation bhi aa jaayega. Score bottom-right corner me dikhta rahega.

Part A — Terminologies

Part B — Unit Testing, Stub & Driver

Part C — Blackbox & Whitebox

Part D — Integration & System Testing

Part E — TDD

Part F — Descriptive / Programming questions

Yeh wo type hain jo programming assignment ya long-answer me aate hain. Pehle khud try karo, phir answer kholo.

import pytest
from inventory import SellerInventory

@pytest.fixture
def inventory():
    return SellerInventory("S1")

def test_add_new_item_to_inventory(inventory):
    inventory.add_items_to_inventory("P1", 10)
    assert inventory.seller_inventory_map["P1"] == 10

def test_add_previously_added_item(inventory):
    inventory.add_items_to_inventory("P1", 10)
    inventory.add_items_to_inventory("P1", 10)
    assert inventory.seller_inventory_map["P1"] == 20

def test_delete_items_less_than_total(inventory):
    inventory.add_items_to_inventory("P1", 10)
    inventory.delete_items_from_inventory("P1", 5)
    assert inventory.seller_inventory_map["P1"] == 5

def test_delete_items_more_than_total(inventory):
    inventory.add_items_to_inventory("P1", 10)
    with pytest.raises(ValueError):
        inventory.delete_items_from_inventory("P1", 20)

1  def grade(marks):
2      if marks < 0 or marks > 100:
3          return "Invalid"
4      if marks >= 40:
5          return "Pass"
6      return "Fail"

# --- RED 1 ---
def test_simple_palindrome():
    assert is_palindrome("madam") == True      # FAIL

# --- GREEN 1 (minimum code) ---
def is_palindrome(s):
    return s == s[::-1]

# --- RED 2 ---
def test_not_palindrome():
    assert is_palindrome("hello") == False     # pehle se PASS

def test_case_insensitive():
    assert is_palindrome("Madam") == True      # FAIL

# --- GREEN 2 ---
def is_palindrome(s):
    s = s.lower()
    return s == s[::-1]

# --- RED 3 (boundary) ---
def test_empty_string():
    assert is_palindrome("") == True

# --- REFACTOR ---
def is_palindrome(s):
    cleaned = s.lower().replace(" ", "")
    return cleaned == cleaned[::-1]