ما هو اختبار الدخان (Smoke Testing)؟ شرح مفصل لاختبارات التحقق من البنية مع أمثلة عملية

Updated يونيو 20, 2026 16 min read

Aldawsari

دقائق القراءة: 16

مقدمة: ضمان استقرار تطبيقك مع اختبار الدخان (Smoke Testing)

قد يبدو هذا الموقف مألوفاً: تم دفع تحديث برمجي إلى بيئة الإنتاج، والآن توجد ميزة حيوية معطلة. كيف يمكنك منع حدوث ذلك في المستقبل؟

في هذا الدليل الشامل، ستتعرف على مفهوم Smoke Testing (اختبار الدخان) وكيف يساعد في اكتشاف الأخطاء الحرجة مبكراً. سنقوم معاً بإنشاء واختبار تطبيق ويب بشكل مجدول، وإرسال تنبيهات في حال فشل الاختبارات. لنبدأ!

1. ما هو اختبار الدخان (Smoke Testing)؟

نشأ مصطلح "smoke test" (اختبار الدخان) في مجال إصلاح الأجهزة. كان الجهاز يُشغل، وإذا تصاعد منه دخان، فإنه يفشل في اختبار الدخان. في سياق تطوير البرمجيات، يُطلق على اختبار الدخان أحياناً اسم "build verification testing" (اختبار التحقق من البنية).

عند تطبيقه على تطبيقات الويب، يتحقق اختبار الدخان من أن أهم الوظائف الأساسية تعمل بشكل صحيح. على سبيل المثال، قد تتضمن اختبارات الدخان لتطبيق مثل Netflix تسجيل الدخول وتشغيل مقطع فيديو. بطبيعتها، لا تغطي اختبارات الدخان كل الاحتمالات والحالات الهامشية المعقدة؛ بدلاً من ذلك، تتحقق من أن تطبيقك ليس معطلاً لدرجة أن أي اختبارات إضافية ستكون مضيعة للوقت والجهد.

2. لماذا يجب أن تهتم باختبار الدخان؟

توفر اختبارات الدخان قيمة كبيرة مقارنة بالجهد المطلوب لإنشائها. وفقاً لشركة Microsoft، تُعد اختبارات الدخان “الطريقة الأكثر فعالية من حيث التكلفة لتحديد وإصلاح العيوب في البرمجيات” بعد مراجعات الكود.

إن مجرد عدد قليل من الاختبارات للميزات الحيوية، مثل تسجيل الدخول، يمكن أن يحسن الجودة بشكل كبير. يساعد اختبار ما يفعله المستخدمون في أغلب الأحيان على ضمان دعم حالات الاستخدام الرئيسية لتطبيقك.

تمنح اختبارات الدخان فريقك أيضاً الثقة لنشر كود جديد. غالباً ما تكون للتغييرات في قاعدة الكود عواقب غير مقصودة وغير معروفة. توفر اختبارات الدخان راحة بال إضافية بأن تطبيقك لن يتعطل عند إصدار هذه الميزة الجديدة الرائعة. إذا قمت بتشغيل اختبارات الدخان في بيئة الإنتاج، يمكنك أيضاً اكتشاف الأخطاء التي فاتتها الاختبارات السابقة. حتى الاختلافات الصغيرة بين البيئات مثل بيئة التطوير staging والإنتاج production يمكن أن تسبب مشكلات. يمكن لاختبارات الدخان تحديد هذه المشكلات قبل أن يكتشفها العميل.

باختصار، تمنحك اختبارات الدخان طبقة أخرى من الحماية ضد تجربة المستخدم السيئة. يساعد التطبيق الذي يعمل بسلاسة فريقك وشركتك وعملائك على أن يكونوا أكثر نجاحاً.

3. إعداد مشروعك لاختبار الدخان

الآن بعد أن تعلمنا ما هو اختبار الدخان، دعنا نبني مسار عمل (pipeline) لاختبار الدخان!

يفترض هذا الدليل أنك تفهم أساسيات command line (سطر الأوامر)، وأن لديك Node.js و npm مثبتين، وتعرف أساسيات JavaScript و Git. يمكنك إعداد اختباراتك داخل مشروع موجود، أو إنشاء مشروع جديد. لإنشاء مشروع جديد، قم بتشغيل الأوامر التالية في سطر الأوامر:

mkdir smoke_tests
cd smoke_tests

إذا لم تكن قد قمت بذلك بالفعل، قم بتهيئة مشروعك لتتمكن من تثبيت حزم Node.js:

npm init -y

الآن دعنا نثبت الأدوات التي نحتاجها لإنشاء اختبارات الدخان الخاصة بنا. سيقوم هذا الدليل بإنشاء اختبارات Playwright و Jest على تطبيق ويب. Playwright هي مكتبة بنتها Microsoft لأتمتة متصفحات Chromium و Firefox و WebKit. أما Jest فهو إطار عمل لإنشاء وتشغيل اختبارات JavaScript.

لإنشاء اختباراتنا وتشغيلها بسرعة، سنستخدم مكتبة QA Wolf مفتوحة المصدر. تقوم QA Wolf بتحويل إجراءات متصفحك إلى كود اختبار Playwright/Jest. كما أنها تشغل اختباراتك في مزود CI مثل GitHub Actions. إذا كنت تفضل استخدام إطار عمل اختبار آخر، فلا يزال بإمكانك اتباع هذا الدليل لتشغيل اختباراتك في CI وإعداد التنبيهات.

لإعداد مشروعك لاختبارات الدخان، قم بتشغيل الأمر التالي في دليل مشروعك:

npm init qawolf

سيُطلب منك تحديد الدليل الذي سيتم حفظ اختباراتك فيه. اضغط Enter لاستخدام الدليل الافتراضي .qawolf، أو اكتب اسماً مختلفاً.

? rootDir: Directory to create tests in (.qawolf)

ستظهر لك بعد ذلك ملاحظة في سطر الأوامر تشير إلى ما إذا كانت اختباراتك ستستخدم TypeScript. لا يحتوي مشروعنا على ملف "tsconfig.json"، لذلك لن تستخدم اختباراتنا TypeScript.

TypeScript ✖️ tsconfig.json not found

الخطوة الأخيرة هي اختيار مزود CI الخاص بك. سيستخدم هذا الدليل GitHub Actions، ولكن يمكنك اختيار مزود آخر إذا أردت. حدد مزود CI الخاص بك في سطر الأوامر واضغط Enter.

? Choose CI Provider (Use arrow keys)
  Azure DevOps
  Bitbucket Pipelines
  CircleCI
❯ GitHub Actions
  GitLab CI/CD
  Jenkins
  Skip CI setup

سيتم بعد ذلك تثبيت الحزم المطلوبة لاختبارات الدخان (Playwright و Jest و QA Wolf). سيتم أيضاً إنشاء ملفين في مشروعك. الأول هو ملف سير عمل workflow لتشغيل اختباراتك في CI. بما أننا اخترنا GitHub Actions، يتم حفظ هذا الملف في ".github/workflows/qawolf.yml". سنناقش هذا الملف لاحقاً. يوجد أيضاً ملف تكوين تم إنشاؤه في "qawolf.config.js". لن نحتاج إلى تعديل هذا الملف.

بعد انتهاء تثبيت التبعيات، تحقق من نجاح التثبيت:

npx qawolf howl

4. إنشاء اختبار دخان عملي

الآن بعد أن تم إعداد مشروعنا، دعنا ننشئ أول اختبار دخان لنا. في هذا الدليل، سنقوم بإنشاء اختبار دخان على TodoMVC، وهو تطبيق بسيط لإدارة المهام. على وجه التحديد، سنختبر أنه يمكننا إنشاء عنصر مهمة، وإكماله، ومسح المهام المكتملة.

لإنشاء اختبارنا، سنستخدم الأمر npx qawolf create. يأخذ هذا الأمر عنوان URL لتطبيقك واسماً اختيارياً للاختبار. سيؤدي تشغيل هذا الأمر إلى فتح متصفح Chromium حيث سيتم تحويل إجراءاتك إلى كود Playwright/Jest. في سطر الأوامر، قم بتشغيل التالي. يمكنك اختيارياً استبدال http://todomvc.com/examples/react بعنوان URL مختلف، و myFirstTest باسم مختلف:

npx qawolf create http://todomvc.com/examples/react myFirstTest

افتح محرر الكود الخاص بك وابحث عن ملف الاختبار الخاص بك (".qawolf/myFirstTest.test.js" في مثالنا). هذا هو المكان الذي سيتم فيه إنشاء كود الاختبار الخاص بك أثناء استخدامك للمتصفح. بمجرد فتح متصفح Chromium على TodoMVC، قم بالإجراءات التالية:

انقر على حقل إدخال المهمة (todo input) لتركيزه.
اكتب "create test!".
اضغط Enter.
انقر لإكمال المهمة.
انقر على "Clear completed" لمسح المهام المكتملة.

في سطر الأوامر، حدد ? Save and Exit واضغط Enter لحفظ اختبارك.

5. مراجعة كود الاختبار

الآن دعنا نلقي نظرة على كود الاختبار الخاص بنا. في محرر الكود الخاص بك، افتح ملف الاختبار الخاص بك (".qawolf/myFirstTest.test.js" في مثالنا). في بداية اختبارنا، نقوم باستيراد qawolf. كما نستورد محددات العناصر selectors من ".qawolf/selectors/myFirstTest.json"، والتي سنناقشها بعد قليل.

const qawolf = require("qawolf");
const selectors = require("./selectors/myFirstTest.json");

ثم يقوم الاختبار بتشغيل متصفح Playwright browser، وهو في حالتنا متصفح Chromium. يقوم بإنشاء Playwright browserContext جديد، وهو جلسة متصفح خاصة (incognito). تُمنح QA Wolf حق الوصول إلى context حتى تتمكن من اكتشاف إجراءاتك. أخيراً، يتم إنشاء Playwright page جديد، مما يفتح علامة تبويب جديدة في المتصفح.

let browser;
let page;

beforeAll(async () => {
  browser = await qawolf.launch();
  const context = await browser.newContext();
  await qawolf.register(context);
  page = await context.newPage();
});

الاختبار نفسه موجود داخل كتلة Jest test بالاسم الذي حددته. ينتقل الاختبار أولاً إلى عنوان URL الخاص بـ TodoMVC. ثم يمر عبر الإجراءات التي قمت بها: إنشاء عنصر مهمة، وإكماله، ومسح المهام المكتملة. يستخدم كل إجراء إحدى طرق Playwright's page methods، مثل click و type.

test('myFirstTest', async () => {
  await page.goto("http://todomvc.com/examples/react");
  await page.click(selectors["0_what_needs_to_b_input"]);
  await page.type(selectors["1_what_needs_to_b_input"], "create test!");
  await page.press(selectors["2_what_needs_to_b_input"], "Enter");
  await page.click(selectors["3_input"]);
  await page.click(selectors["4_button"]);
});

الوسيطة الأولى التي يتم تمريرها إلى كل طريقة page method هي محدد HTML selector. يخبر هذا المحدد Playwright العنصر الذي يجب التفاعل معه، مثل حقل إدخال المهمة أو زر "Clear completed". يتم استيراد هذه المحددات من ملف ".qawolf/selectors/myFirstTest.json"، والذي يبدو كالتالي:

{
  "0_what_needs_to_b_input": "html=<div data-reactid=".0" qaw_innertext="todos"><header class="header" data-reactid=".0.0" qaw_innertext="todos"><input class="new-todo" placeholder="What needs to be done?" value="" data-reactid=".0.0.1" /></header></div>",
  // ...
}

يتم تخزين كل سمة من سمات العنصر الذي تفاعلت معه، بالإضافة إلى سمات اثنين من أسلافه، في هذا الملف. عند تشغيل اختبارك، سيبذل قصارى جهده للعثور على تطابق جيد بما فيه الكفاية لـ HTML المحدد. من خلال عدم الاعتماد على سمة واحدة، تكون اختباراتك أكثر قوة في مواجهة التغييرات في كود الواجهة الأمامية.

تدعم طرق Playwright page methods أيضاً أنواعاً أخرى من المحددات، مثل محددات CSS أو محددات النص. على سبيل المثال، يمكنك استبدال selectors["4_button"] في الخطوة الأخيرة بمحدد CSS '.clear-completed'.

test('myFirstTest', async () => {
  // ...
  // change this
  await page.click(selectors["4_button"]);
  // to this (CSS selector)
  await page.click('.clear-completed');
});

يمكنك اختيارياً تكوين QA Wolf لاستخدام سمات الاختبار مثل data-qa في الكود الذي تم إنشاؤه كلما أمكن ذلك.

بعد انتهاء الاختبار من التشغيل، توقف QA Wolf عن تسجيل أي مقاطع فيديو للمتصفح إذا كان ذلك ينطبق. يتم إغلاق المتصفح أيضاً.

afterAll(async () => {
  await qawolf.stopVideos();
  await browser.close();
});

بجمع كل ذلك معاً، يبدو كود الاختبار الكامل كالتالي:

const qawolf = require("qawolf");
const selectors = require("./selectors/myFirstTest.json");

let browser;
let page;

beforeAll(async () => {
  browser = await qawolf.launch();
  const context = await browser.newContext();
  await qawolf.register(context);
  page = await context.newPage();
});

afterAll(async () => {
  await qawolf.stopVideos();
  await browser.close();
});

test("myFirstTest", async () => {
  await page.goto("http://todomvc.com/examples/react");
  await page.click(selectors["0_what_needs_to_b_input"]);
  await page.type(selectors["1_what_needs_to_b_input"], "create test!");
  await page.press(selectors["2_what_needs_to_b_input"], "Enter");
  await page.click(selectors["3_input"]);
  await page.click(selectors["4_button"]);
});

إذا لم يتمكن الاختبار من إكمال سير العمل، فسيفشل. يمكنك تعديل كود الاختبار الخاص بك، مثل إضافة تأكيدات assertions. لن نتناول ذلك في هذا الدليل، ولكن هناك أدلة أخرى إذا كنت ترغب في معرفة المزيد. الآن بعد أن فهمنا كود الاختبار الخاص بنا، دعنا نشغل اختبارنا!

6. تشغيل اختبارك محلياً

دعنا نشغل اختبارنا محلياً للتأكد من أنه يعمل. في سطر الأوامر، قم بتشغيل التالي لتشغيل اختبارك (اختباراتك) باستخدام Jest:

npx qawolf test

يجب أن ترى متصفح Chromium يفتح ويشغل الاختبار. سيعمل اختبارك بأسرع ما يمكن، لذا لا تتفاجأ إذا تم تشغيله بسرعة.

7. تشغيل الاختبارات باستخدام GitHub Actions

في هذا الدليل، سنقوم بتشغيل اختباراتنا بجدول زمني، مثل كل ساعة. يضمن تشغيل الاختبارات بجدول زمني أن تطبيقك يعمل بشكل مستمر. يمكنه أيضاً كشف المشكلات الدورية، أو "flakes"، التي تظهر أحياناً فقط. في هذا الدليل، نستخدم GitHub Actions لتشغيل اختباراتنا. GitHub Actions هي أداة لأتمتة سير عمل البرامج، مثل نشر خدمة ويب أو اختبار تطبيق.

مراجعة ملف سير العمل (Workflow File)

عندما قمنا بإعداد مشروعنا، تم إنشاء ملف YAML يسمى ".github/workflows/qawolf.yml". سنقوم أولاً بالمرور سريعاً على الأجزاء المختلفة من هذا الملف. ثم سنقوم بتحديثه بحيث يتم تشغيل اختباراتنا بجدول زمني.

يسمي السطر الأول من ملف سير العمل سير عملنا. هذا هو الاسم الذي سيظهر في GitHub Actions، ويمكنك تغييره إذا أردت.

name: qawolf

ثم تحدد مفتاح on الحدث الذي يجب أن يؤدي إلى تشغيل اختباراتنا. بشكل افتراضي، سيتم تشغيل اختباراتك كلما قام شخص ما بالدفع إلى أي فرع. سنقوم قريباً بتعديل هذا لتشغيل اختباراتنا أيضاً بجدول زمني.

on:
  push:
    # test every branch
    # edit below if you only want certain branches tested
    branches: "*"
  # schedule:
  #   # test on schedule using cron syntax
  #   - cron: "0 * * * *" # every hour

بقية الملف تحدد ما يجب أن يفعله GitHub Actions عند تشغيله. سيقوم GitHub Actions بتشغيل أي مهام مدرجة تحت مفتاح jobs. في حالتنا، لدينا مهمة واحدة فقط تشغل اختباراتنا. على وجه التحديد، تقوم مهمة test الخاصة بنا بتثبيت التبعيات، وسحب الكود الخاص بنا، وتشغيل أمر الاختبار npx qawolf test. بعد تشغيل الاختبار (الاختبارات)، يتم حفظ عناصر تصحيح الأخطاء مثل سجلات وحدة التحكم ومقاطع الفيديو.

jobs:
  test:
    runs-on: ubuntu-18.04
    steps:
      - name: Install dependencies
        run: |
          sudo apt update
          # chromium dependencies
          sudo apt-get install libgbm1
          # webkit dependencies
          sudo apt-get install libwoff1 libopus0 libwebp6 libwebpdemux2 libenchant1c2a libgudev-1.0-0 libsecret-1-0 libhyphen0 libgdk-pixbuf2.0-0 libegl1 libgles2 libevent-2.1-6 libnotify4 libvpx5 libxslt1.1
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
      - uses: actions/cache@v1
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
      - run: npm install
      # - name: Start local server
      #   run: npm run start & npx wait-on http://localhost:3000
      - run: npx qawolf test --headless
        env:
          # configure tests with environment variables
          QAW_ARTIFACT_PATH: ${{ github.workspace }}/artifacts
          # you can also use GitHub secrets for environment variables
          # https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
          # LOGIN_PASSWORD: ${{ secrets.PASSWORD }}
      - name: Upload Artifacts
        if: always()
        uses: actions/upload-artifact@master
        with:
          name: qawolf
          path: ${{ github.workspace }}/artifacts

تشغيل الاختبارات في GitHub Actions

الآن بعد أن فهمنا ملف سير العمل الخاص بنا بشكل أفضل، دعنا نشغله في GitHub Actions. إذا لم تكن قد قمت بذلك بالفعل، فقم بإنشاء مستودع Git لمشروعك. تأكد من تجاهل node_modules/ في ملف ".gitignore" الخاص بك.

git init
git add .
git commit -m "Initial commit"

تأكد من أنك قمت بإنشاء مستودع لمشروعك على GitHub. ثم ادفع الكود الخاص بك إلى GitHub.

git remote add origin YOUR_REPOSITORY_URL
git push -u origin master

الآن اذهب إلى مستودع GitHub الخاص بك وانقر على علامة التبويب "Actions"، والتي تقع بجوار علامة التبويب "Pull Requests".

سترى أن اختباراتك قيد التشغيل. هذا لأن ملف سير العمل الخاص بنا أخبر GitHub بتشغيل اختباراتنا كلما قام أي شخص بالدفع إلى أي فرع. انقر على تشغيل سير العمل لعرض التفاصيل. لاحظ أن الاسم سيختلف اعتماداً على رسالة الالتزام الخاصة بك.

بعد تشغيل اختبارك، يجب أن ترى علامة خضراء تشير إلى أن سير العمل كان ناجحاً. يجب أن ترى أيضاً رابطاً لتنزيل artifacts (الفيديو والسجلات) تحت "Artifacts". انقر على هذا الرابط لتنزيل artifacts الاختبار.

يتم تنظيم artifacts في مجلد واحد لكل اختبار. في مثالنا، لدينا اختبار واحد فقط يسمى "myFirstTest.test.js". افتح هذا المجلد لرؤية سجلات المتصفح في الملف "logs 0 ${timestamp}.txt" وفيديو "video 0 ${timestamp}.mp4". يشير الرقم 0 في أسماء الملفات إلى فهرس الصفحة. إذا كان اختبارك يتضمن أكثر من صفحة واحدة، فسيكون هناك سجلات ومقاطع فيديو مقابلة لكل صفحة إضافية.

الآن دعنا نحدّث ملف سير العمل الخاص بنا لتشغيل اختباراتنا بجدول زمني أيضاً. في ملف ".github/workflows/qawolf.yml"، قم بإلغاء التعليق عن الأسطر 7-9.

name: qawolf
on:
  push:
    # test every branch
    # edit below if you only want certain branches tested
    branches: "*"
  schedule:
    # test on schedule using cron syntax
    - cron: "0 * * * *" # every hour

تخبر هذه الأسطر GitHub بتشغيل اختباراتك بجدول زمني محدد باستخدام صيغة cron. القيمة الافتراضية هي "0 * * * *"، مما يعني التشغيل كل ساعة على رأس الساعة. قم بتحديث هذه القيمة إذا كنت ترغب في استخدام فاصل زمني مختلف.

سنغير شيئاً آخر في ملف سير العمل الخاص بنا. لدى GitHub Actions حد تخزين لـ artifacts، لذلك لا نريد تحميلها في كل مرة. بدلاً من ذلك، سنقوم بتحميل السجلات ومقاطع الفيديو فقط عند فشل الاختبارات. قم بتحديث السطر 51 من if: always() إلى if: failure().

# ...
      - name: Upload Artifacts
        if: failure()
        uses: actions/upload-artifact@master
        with:
          name: qawolf
          path: ${{ github.workspace }}/artifacts

قم بتثبيت تغييراتك وادفعها إلى GitHub.

git add .
git commit -m "Run tests on a schedule"
git push

الآن ستعمل اختبارات الدخان الخاصة بك كل ساعة على GitHub Actions!

8. إعداد التنبيهات مع Slack

الجزء الأخير من مسار عملنا هو نظام تنبيه يخبرنا عند فشل اختباراتنا. في هذا الدليل، نستخدم Slack لأنه يحتوي على خطة مجانية. يمكنك أيضاً استخدام خدمة مثل PagerDuty، والتي سيكون لها عملية إعداد مماثلة.

إذا لم يكن لديك حساب ومساحة عمل في Slack بالفعل، فقم بإنشائهما الآن.

إنشاء Slack Webhook

سنقوم الآن بإنشاء Slack webhook، وهو عنوان URL يسمح لنا بإرسال رسائل Slack برمجياً. سنقوم بإجراء طلب POST إلى عنوان URL هذا عند فشل اختباراتنا.

أولاً، نحتاج إلى إنشاء تطبيق Slack، والذي سيكون مسؤولاً عن إرسال رسائل التنبيه الخاصة بنا. ابدأ بزيارة موقع Slack API. في الزاوية العلوية اليمنى يوجد زر أخضر "Create New App".

انقر على هذا الزر وسيُطلب منك تسمية تطبيق Slack الخاص بك واختيار مساحة عمل. في مثالنا، نسمي تطبيقنا "smoke-tests". بعد ملء النموذج، انقر على الزر الأخضر "Create App".

يجب أن يتم توجيهك إلى صفحة تطبيقك في Slack. تأكد من أنك في صفحة "Basic Information" تحت "Settings". تحت "Add features and functionality"، يوجد رابط لـ "Incoming Webhooks". انقر على هذا الرابط.

في صفحة Incoming Webhooks، انقر على زر التبديل لتشغيل incoming webhooks.

ستتمكن بعد ذلك من رؤية زر "Add New Webhook to Workspace" في أسفل الصفحة. انقر على هذا الزر لإضافة webhook جديد. سنستخدم هذا webhook لإرسال رسالة Slack عند فشل اختباراتنا.

سيُطلب منك بعد ذلك اختيار القناة التي سيتم نشر رسائلك فيها. في مثالنا، نختار قناة "alerts". بعد اختيار قناتك، انقر على الزر الأخضر "Allow".

سيتم توجيهك إلى صفحة webhooks. تحت "Webhook URLs for Your Workspace"، يجب أن ترى الآن عنوان URL الخاص بـ webhook الخاص بك.

لاختبار webhook الخاص بك، انسخ الكود تحت "Sample curl request to post to a channel". سيبدو شيئاً كالتالي:

curl -X POST -H 'Content-type: application/json' --data '{"text":"Hello, World!"}' https://hooks.slack.com/services/SECRET

الصقه في سطر الأوامر واضغط Enter. سترى الرسالة "Hello, World!" منشورة في القناة التي حددتها.

إرسال تنبيه عند فشل الاختبارات

الآن بعد أن أصبح لدينا Slack webhook، نحتاج إلى تحديث ملف سير عمل GitHub Actions الخاص بنا. سنضيف خطوة تقوم بإجراء طلب POST إلى webhook الخاص بنا عند فشل الاختبارات.

بدلاً من لصق عنوان URL الخاص بـ webhook مباشرة في ملف سير العمل الخاص بنا، سنضيفه إلى أسرار المستودع repository secrets. الأسرار هي متغيرات بيئة مشفرة تخزن معلومات حساسة. الحفاظ على سرية عنوان URL الخاص بـ webhook يمنع الآخرين من رؤيته وربما استخدامه لأغراض غير مرغوبة.

أضف سراً جديداً ضمن إعدادات المستودع الخاص بك. سمِ سرك SLACK_WEBHOOK_URL، واضبط قيمته على عنوان URL الخاص بـ Slack webhook.

الآن دعنا نحدّث ملف سير العمل الخاص بنا. في أسفل ملف ".github/workflows/qawolf.yml"، أضف الأسطر التالية. تخبر هذه الأسطر GitHub بإجراء طلب POST إلى Slack webhook الخاص بك عند فشل اختباراتك. لقد غيرنا القيمة التي تم تمريرها إلى "text" من "Hello, World!" إلى "Smoke tests failed!"، ولكن يمكنك استخدام أي رسالة تريدها. لاحظ أننا لا نستخدم قيمة عنوان URL الخاص بـ Slack webhook مباشرة، بل نستبدلها بـ ${{ secrets.SLACK_WEBHOOK_URL }}.

# ...
      - name: Upload Artifacts
        if: failure()
        uses: actions/upload-artifact@master
        with:
          name: qawolf
          path: ${{ github.workspace }}/artifacts

      # add the following lines
      - name: Post Slack Message
        if: failure()
        run: |
          curl -X POST -H 'Content-type: application/json' --data '{"text":"Smoke tests failed!"}' ${{ secrets.SLACK_WEBHOOK_URL }}

إذا كنت ترغب في اختبار أن webhook يعمل، قم بإلقاء خطأ في ملف الاختبار الخاص بك ".qawolf/myFirstTest.test.js". ثم ادفع تغييراتك إلى GitHub.

test("myFirstTest", async () => {
  await page.goto("http://todomvc.com/examples/react");
  await page.click(selectors["0_what_needs_to_b_input"]);
  await page.type(selectors["1_what_needs_to_b_input"], "create test!");
  await page.press(selectors["2_what_needs_to_b_input"], "Enter");
  await page.click(selectors["3_input"]);
  await page.click(selectors["4_button"]);
  // add this line
  throw new Error("demogorgon!");
});

سيفشل اختبارك، وسيتم نشر رسالة في Slack. ستتمكن أيضاً من تنزيل artifacts. بعد الانتهاء من اختبار webhook الخاص بك، تأكد من إزالة الخطأ من كود الاختبار الخاص بك.

9. الخلاصة

إذا وصلت إلى هذا الحد، فتهانينا! في هذا الدليل، تعلمنا عن اختبارات الدخان وقمنا ببناء مسار عمل (pipeline) لاختبار الدخان. الآن يمكنك أن تكون بطل فريقك في اختبار الدخان!

الخلاصة التقنية

يمثل اختبار الدخان (Smoke Testing) حجر الزاوية في استراتيجيات ضمان الجودة الحديثة، خاصة في بيئات التطوير السريع والتسليم المستمر (CI/CD). إنه لا يقتصر على الكشف عن الأخطاء الفادحة مبكراً فحسب، بل يوفر أيضاً طبقة أساسية من الثقة بأن البنية البرمجية (build) مستقرة بما يكفي لمزيد من الاختبارات التفصيلية أو حتى للنشر. من خلال أتمتة هذه الاختبارات وربطها بأنظمة التنبيه مثل Slack، يمكن للفرق التقنية الاستجابة فوراً للمشكلات، مما يقلل بشكل كبير من وقت التوقف المحتمل ويحافظ على تجربة مستخدم إيجابية. إن الاستثمار في اختبارات الدخان هو استثمار في كفاءة الفريق، وجودة المنتج، ورضا العملاء.