پوسٹ مین کلیکشن کو برقرار رکھنے کے قابل پائٹیسٹ سوٹ میں کیسے تبدیل کیا جائے۔

پوسٹ مین کلیکشن API کو دریافت کرنے کے لیے ایک بہترین جگہ ہے۔ تاہم، یہ آپ کے ٹیسٹوں کو ذخیرہ کرنے کے لیے اچھی جگہ نہیں ہے۔

زیادہ تر ٹیمیں اسے سست طریقے سے نکالتی ہیں۔ کوئی مجموعہ برآمد کرتا ہے، درخواست کا ایک بار ٹیسٹ کوڈ میں ترجمہ کرتا ہے، اور آگے بڑھتا ہے۔ 6 ماہ کے بعد، ٹیسٹ سرخ ہو جائے گا، کوئی بھی اس پر بھروسہ نہیں کرے گا، اور اسے پائپ لائن میں چھوڑ دیا جائے گا. منتقلی بالکل مشکل حصہ نہیں تھا۔ یہ سویٹ کو زندہ رکھنے کے بارے میں ہے۔

یہ ٹیوٹوریل آپ کو pytest سوٹ کے ذریعے لے جاتا ہے، جو پوسٹ مین مجموعہ میں درج ذیل شاخوں سے گزرتا ہے: پہلے، ہم دیکھیں گے کہ تبدیل شدہ ٹیسٹ کیوں کرپٹ ہو جاتے ہیں، اور پھر ہم ان کو زندہ رکھنے کے لیے چار اصول دیکھیں گے۔ مثالیں چھوٹی رکھی گئی ہیں، لہذا آپ انہیں آج ہی اپنے مجموعے کے لیے آزما سکتے ہیں۔

انڈیکس

اس سے پہلے کہ آپ شروع کریں۔

پیروی کرنے کے لیے آپ کو ضرورت ہو گی:

Pytest اور httpx انسٹال کے ساتھ Python 3.10 یا اس سے زیادہ (pip install pytest httpx)۔
پوسٹ مین مجموعہ جسے آپ ماحول کے ساتھ تبدیل کرنا چاہتے ہیں (بیس یو آر ایل اور ٹوکن)۔
بنیادی پیسٹسٹ علم: فکسچر کیسے کام کرتے ہیں اور انہیں کیسے چلانا ہے۔ pytest کمانڈ لائن سے۔
اگر آپ مسلسل انضمام کے مراحل کو آزمانا چاہتے ہیں تو GitHub ذخیرہ۔ آپ اس حصے کو چھوڑ سکتے ہیں اور باقی کی پیروی جاری رکھ سکتے ہیں۔

خاکہ کام کے دو حصے دکھاتا ہے۔ بائیں طرف، پوسٹ مین کے مجموعے (مطابق درخواستیں اور ماحول) ایک جنریٹڈ پائیٹیسٹ سوٹ میں تبدیل ہو جاتے ہیں، جو کہ پہلا مسودہ ہے۔ منتقلی ایک آسان مرحلہ ہے۔

کام دائیں طرف دیکھ بھال کی پرت ہے، جو پہلے مسودے کو ایک قابل اعتماد پروڈکٹ لائن میں بدل دیتی ہے۔ ماحول ہارڈ کوڈ ہونے کے بجائے فکسچر میں موجود ہے، ٹیسٹ 200 سٹیٹس کے بجائے جوابی معاہدوں کی جانچ کرتے ہیں، ہر ٹیسٹ خود مختار ہوتا ہے، اور سویٹ ہر پش کے ساتھ مسلسل انضمام میں چلتا ہے۔

تبدیل شدہ ٹیسٹ کیوں پرانے ہیں۔

اگر آپ پوسٹ مین کی درخواستوں کا ون ٹو ون ترجمہ کرتے ہیں تو آپ کو چار عادتیں وراثت میں ملتی ہیں جو آپ کو پہلے دن اچھا محسوس کرتی ہیں لیکن تیس دن آپ کو تکلیف دیتی ہیں۔

پہلے سے طے شدہ URL اور ٹوکن کو ہر ٹیسٹ میں ہارڈ کوڈ کیا جاتا ہے، لہذا آپ کو اسٹیجنگ سے پروڈکشن کی طرف جانے کے لیے انہیں تلاش کرنے اور تبدیل کرنے کی ضرورت ہوگی۔
چونکہ Request 2 کا انحصار Request 1 سیٹ میں موجود اقدار پر ہے، اس لیے ٹیسٹ ایک مقررہ ترتیب میں چلائے جاتے ہیں۔ لہذا ایک ہی ناکامی جھرن کی طرف جاتا ہے۔
صرف دلیل یہ ہے کہ یہ گزر جاتا ہے چاہے اسٹیٹس کوڈ 200 ہو اور رسپانس باڈی غلط ہو۔
ترتیبات کو تمام ٹیسٹوں میں کاپی کیا جاتا ہے، لہذا آپ تصدیق کے طریقہ کار کو ایک بار تبدیل کرکے 20 فائلوں میں ترمیم کرسکتے ہیں۔

یہ سب دیکھ بھال کے مسائل ہیں، اور یہ ایک ساتھ مل کر ایک پروڈکٹ لائن کے ریٹائر ہونے کی وجہ ہیں۔ یہاں ہر ایک سے بچنے کا طریقہ ہے:

اصول 1: ماحول کو آزمائش سے دور رکھیں

پوسٹ مین کے مجموعے اپنے ماحول کو علیحدہ فائلوں میں منتقل کرتے ہیں جنہیں بیس یو آر ایل، ٹوکنز اور دیگر متغیر کہتے ہیں۔ pytest میں بھی ایسا ہی کریں۔ فکسچر سے اس قدر کو ایک بار پڑھیں اور ہر ٹیسٹ سے اس قدر کی درخواست کریں۔

# conftest.py
import os

import httpx
import pytest


@pytest.fixture(scope="session")
def base_url():
    return os.environ["API_BASE_URL"]


@pytest.fixture(scope="session")
def auth_headers():
    return {"Authorization": f"Bearer {os.environ['API_TOKEN']}"}


@pytest.fixture()
def http():
    with httpx.Client(timeout=10) as client:
        yield client

ٹیسٹ اب براہ راست URLs یا ٹوکنز کا ذکر نہیں کرتا ہے۔

def test_get_user(base_url, auth_headers, http):
    response = http.get(f"{base_url}/users/1", headers=auth_headers)
    assert response.status_code == 200

اب، اسٹیجنگ سے پروڈکشن میں منتقلی پورے سوٹ کی تلاش کے بجائے ایک ماحولیاتی متغیر ہے۔

اصول 2: معاہدوں کے بارے میں دعوی کریں، نہ کہ صرف اسٹیٹس کوڈز

اسٹیٹس 200 بتاتا ہے کہ سرور نے جواب دیا۔ یہ آپ کو یہ نہیں بتاتا کہ جواب درست ہے۔ ٹوٹے ہوئے API کے جاری ہونے کی سب سے عام وجہ یہ ہے کہ تمام ٹیسٹ صرف حالت کی جانچ کرتے ہیں۔

جواب کی شکل چیک کریں اور کال کرنے والا کن فیلڈز پر انحصار کرتا ہے۔

def test_user_shape(base_url, auth_headers, http):
    response = http.get(f"{base_url}/users/1", headers=auth_headers)

    assert response.status_code == 200
    body = response.json()
    assert set(body) >= {"id", "email", "created_at"}
    assert isinstance(body["id"], int)
    assert "@" in body["email"]

آپ کو ہر اختتامی نقطہ کے لیے سخت اسکیما کی ضرورت نہیں ہے۔ اہم شعبوں پر صرف چند چیک ہی صحت کی جانچ سے گزرنے والے رجعت کے پورے طبقے کو پکڑ سکتے ہیں۔

اصول 3: ہر امتحان کو اس کا اپنا بنائیں۔

پوسٹ مین میں، ایک درخواست کے لیے اگلی درخواست کو آگے بڑھانا عام ہے۔ ٹیسٹ سوٹ میں، یہ مجموعہ ایک جال ہے۔ اپنے ٹیسٹوں کی ترتیب کو تبدیل کریں، انہیں اکیلے چلائیں، یا پہلی درخواست کھو دیں اور باقی کو فیل کر دیں۔

ہر ٹیسٹ کے لیے مطلوبہ حیثیت فراہم کریں۔ اگر آپ کو اپنے ٹیسٹوں کے لیے صارفین کی ضرورت ہے تو صارفین بنائیں۔

def test_delete_user(base_url, auth_headers, http):
    created = http.post(
        f"{base_url}/users",
        headers=auth_headers,
        json={"email": "temp@example.com"},
    )
    user_id = created.json()["id"]

    response = http.delete(f"{base_url}/users/{user_id}", headers=auth_headers)
    assert response.status_code == 204

آزاد ٹیسٹ کسی بھی ترتیب میں متوازی طور پر چلائے جا سکتے ہیں اور غلطیاں سلسلہ کی بجائے ایک چیز کی طرف اشارہ کرتی ہیں۔

اصول 4: پہلے دن سے اپنی پروڈکٹ لائن میں مسلسل انضمام کا اطلاق کریں۔

ایک ٹیسٹ سویٹ جو صرف آپ کے لیپ ٹاپ پر چلتا ہے اس وقت پرانا ہو جاتا ہے جب آپ اسے دیکھنا چھوڑ دیتے ہیں۔ اس سے پہلے کہ ہم دوسرا ٹیسٹ لکھیں، ہمیں اسے پائپ لائن سے جوڑنے کی ضرورت ہے اور اس بات کو یقینی بنانا ہوگا کہ جب بھی ہم دبائیں گے تو یہ سبز رہے۔

# .github/workflows/tests.yml
name: API tests
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest -v
        env:
          API_BASE_URL: ${{ secrets.API_BASE_URL }}
          API_TOKEN: ${{ secrets.API_TOKEN }}

جب یہ عمل میں آتا ہے، تو وہ ٹیسٹ جو ٹوٹ جاتے ہیں وہ پل کی درخواست پر ہونے والی گفتگو ہیں، پیداوار میں حیران کن نہیں۔

مذکورہ بالا تمام باتیں قابل توجہ ہیں۔ ہر درخواست کو ٹیسٹ کے پہلے مسودے میں تبدیل کرنا مکینیکل ہے، اور مکینیکل کام خودکار ہونے کے قابل ہیں۔

مجھے بالکل اس مرحلے کے لیے ایک اوپن سورس ٹول ملا: postman2pytest. پوسٹ مین مجموعے کو پڑھتا ہے اور ایک قابل عمل پائٹیسٹ فائل لکھتا ہے، اس لیے یہ تیار کردہ ٹیسٹوں سے شروع ہوتا ہے اور اپنا وقت بوائلر پلیٹ کے بجائے دیکھ بھال کی پرت پر صرف کرتا ہے۔ جب آپ کا مجموعہ تبدیل ہوتا ہے، تو ہم اسے دستی طور پر پیچ کرنے کے بجائے اسے دوبارہ بناتے ہیں۔

آپ اسے یہاں تلاش کر سکتے ہیں: https://github.com/golikovichev/postman2pytest

ختم

پوسٹ مین مجموعہ کو ٹیسٹ میں تبدیل کرنا آسان ہے۔ ان ٹیسٹوں کو قابل اعتماد رکھنا ایک حقیقی مہارت ہے اور یہ چند عادات تک آتی ہے۔ ماحول کو اپنے ٹیسٹوں سے دور رکھیں، معاہدوں کے ساتھ ساتھ ریاستی کوڈ پر زور دیں، ہر ٹیسٹ کو خود مختار بنائیں، اور شروع سے ہی مسلسل انضمام کے ساتھ ہر چیز کو چلائیں۔

اس طرح، آپ جو خاندان اس ہفتے بنائیں گے وہ خاندان ہوں گے جنہیں آپ اگلے سال استعمال کرنا جاری رکھیں گے۔