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

في هذا الدليل، سنستكشف ماهية CDCT، وكيف تعمل، وأهميتها في ضمان تفاعلات الخدمات الصغيرة الموثوقة، وكيف يمكنك تنفيذها باستخدام أدوات مثل Pact.

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

المصطلحات الأساسية:
• المستهلك: الخدمة التي تستهلك واجهة برمجة التطبيقات.
• المزود (المنتج): الخدمة التي توفر واجهة برمجة التطبيقات (API).
• العقد: اتفاقية رسمية بين المستهلك والمزود تحدد سلوك واجهة برمجة التطبيقات (API) المتوقع.

كيف يعمل؟

1. يحدد المستهلك العقد: يحدد المستهلك توقعاته حول كيفية تصرف واجهة برمجة التطبيقات الخاصة بالموفر (على سبيل المثال، نقاط النهاية وتنسيقات البيانات ورموز حالة الاستجابة التي يتوقعها).
2. العقد مشترك: يشارك المستهلك هذا العقد مع المزود. يعد هذا العقد بمثابة مواصفات لما يجب على المزود الوفاء به.
3. يقوم المزود بالتحقق من العقد: يقوم المزود باختبار نفسه وفقًا لعقد المستهلك، مما يضمن أنه يفي بتوقعات المستهلك.
4. حلقة الملاحظات المستمرة: سيتم اكتشاف أي تغييرات عاجلة على واجهة برمجة التطبيقات الخاصة بالموفر مبكرًا حيث يجب على المزود التحقق من صحة عقود جميع المستهلكين. وهذا يخلق شبكة أمان لضمان أن التغييرات في المزود لا تؤثر سلبًا على المستهلكين.

أهمية اختبار العقود التي يحركها المستهلك
في البنى الموزعة، خاصة مع الخدمات الصغيرة، تصبح إدارة التبعيات بين الخدمات أكثر تعقيدًا. يساعد CDCT في تخفيف هذا التعقيد بعدة طرق:

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

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

3. دورات تطوير أسرع
مع CDCT، يمكن تطوير واختبار كل من المستهلك والمزود بالتوازي، مما يؤدي إلى تسريع عملية التطوير. يمكن لمقدمي الخدمات اختبار عقد المستهلك حتى قبل أن ينفذ المستهلك وظائفه بشكل كامل.

4. الكشف المبكر عن مخالفات العقود
يتم الكشف عن التغييرات التي تطرأ على الموفر والتي تنتهك العقد في وقت مبكر من عملية التطوير، مما يمكّن المطورين من معالجة المشكلات قبل أن تصبح حرجة.

كيفية تنفيذ اختبار العقود بناءً على المستهلك
تتوفر العديد من الأدوات لتنفيذ CDCT، ويعد Pact واحدًا من أكثر الأدوات شيوعًا. يسمح الميثاق للمستهلكين بتحديد عقودهم ومقدمي الخدمات للتحقق منها.

إليك دليل خطوة بخطوة لتنفيذ CDCT باستخدام Pact:
الخطوة 1: تحديد توقعات المستهلك
أولا، في خدمة المستهلك، تحديد العقد. يتضمن هذا عادةً ما يلي:
• نقطة النهاية التي سيتصل بها المستهلك.
• طريقة الطلب (GET، POST، PUT، إلخ).
• نص الطلب المتوقع أو المعلمات.
• هيئة الاستجابة المتوقعة ورمز الحالة.
فيما يلي مثال على تحديد عقد في اختبار المستهلك باستخدام Pact في JavaScript:

const { Pact } = require('@pact-foundation/pact');
const path = require('path');

const provider = new Pact({
    consumer: 'UserService',
    provider: 'UserAPI',
    port: 1234,
    log: path.resolve(process.cwd(), 'logs', 'pact.log'),
    dir: path.resolve(process.cwd(), 'pacts'),
});

describe('Pact Consumer Test', () => {
    beforeAll(() => provider.setup());

    afterAll(() => provider.finalize());

    it('should receive user details from the API', async () => {
        // Define the expected interaction
        await provider.addInteraction({
            state: 'user exists',
            uponReceiving: 'a request for user details',
            withRequest: {
                method: 'GET',
                path: '/users/1',
                headers: {
                    Accept: 'application/json',
                },
            },
            willRespondWith: {
                status: 200,
                headers: {
                    'Content-Type': 'application/json',
                },
                body: {
                    id: 1,
                    name: 'John Doe',
                },
            },
        });

        // Make the actual request and test
        const response = await getUserDetails(1);
        expect(response).toEqual({ id: 1, name: 'John Doe' });
    });
});

في هذا المثال، يتوقع المستهلك (UserService) من الموفر (UserAPI) أن يقوم بإرجاع تفاصيل المستخدم عند تقديم طلب GET إلى /users/1.

الخطوة 2: نشر العقد
بمجرد اجتياز اختبار المستهلك، يقوم Pact بإنشاء ملف عقد (ملف Pact) يمكن مشاركته مع الموفر. يمكن تخزين هذا العقد في وسيط Pact أو نظام التحكم في الإصدار حتى يتمكن المزود من استخدامه للتحقق.

الخطوة 3: يتحقق المزود من العقد
يقوم المزود باسترجاع العقد والتحقق من أنه يتوافق مع توقعات المستهلك. ويتم ذلك عن طريق إجراء اختبار Pact من جانب الموفر. فيما يلي مثال للتحقق من عقد Pact في Java:

public class ProviderTest {

    @Test
    public void testProviderAgainstPact() {
        PactVerificationResult result = new PactVerifier()
            .verifyProvider("UserAPI", "pacts/UserService-UserAPI.json");

        assertThat(result, instanceOf(PactVerificationResult.Ok.class));
    }
}

يجري المزود هذا الاختبار للتأكد من التزامه بالعقد المحدد من قبل المستهلك.

الخطوة 4: التكامل المستمر
بمجرد دمج CDCT في مسار CI/CD الخاص بك، في كل مرة يتغير فيها العقد، يمكن للموفر التحقق تلقائيًا من العقد. وهذا يضمن أن تغييرات واجهة برمجة التطبيقات (API) لا تخالف توقعات المستهلك، مما يوفر شبكة أمان لكلا الفريقين.

أفضل ممارسات CDCT

1. عقود صغيرة ومركزة: تأكد من أن عقودك صغيرة وتركز فقط على احتياجات المستهلك. وهذا يمنع التعقيد غير الضروري في العقد ويبسط عملية التحقق.
2. إصدار العقد: قم دائمًا بإصدار العقود الخاصة بك. يتيح ذلك لمقدمي الخدمات التعامل مع إصدارات متعددة من نفس العقد، مما يساعدك على دعم المستهلكين المختلفين في مراحل مختلفة من التطوير.
3. النشر المستقل: تأكد من أن CDCT جزء من خط أنابيب CI/CD الخاص بك. يجب أن تؤدي أي تغييرات يتم إجراؤها على المستهلك أو المزود إلى إجراء اختبارات العقد لتجنب تعطل بيئات الإنتاج.
4. استخدام وسيط Pact: وسيط Pact هو مستودع مركزي يقوم بتخزين عقودك ويسمح لكل من المستهلكين ومقدمي الخدمات باستردادها. كما يوفر أيضًا واجهة مستخدم لتصور إصدارات العقد وتبعياته.

متى يتم استخدام اختبار العقود الموجه من قبل المستهلك
يكون CDCT مفيدًا بشكل خاص عندما:
• لديك خدمات صغيرة أو بنيات موزعة مع تفاعل خدمات متعددة.
• تحتاج الفرق التي تعمل على خدمات مختلفة إلى التطوير بشكل مستقل دون إجراء اختبارات تكامل متكررة.
• من المرجح أن تتغير عقود واجهة برمجة التطبيقات (API) كثيرًا، وتريد تجنب كسر توقعات المستهلك.
• أنت بحاجة إلى حلقات ردود فعل سريعة لاكتشاف انتهاكات العقود في وقت مبكر من عملية التطوير.

خاتمة
يوفر اختبار العقود الذي يعتمد على المستهلك طريقة موثوقة لضمان تواصل الخدمات في النظام الموزع بشكل فعال دون كسر التغييرات. من خلال التركيز على توقعات المستهلكين والتحقق من صحة مقدم الخدمة مقابلها، تساعد CDCT الفرق على التطور بشكل مستقل مع ضمان الاستقرار. سواء كنت تقوم بإنشاء خدمات صغيرة أو تطبيقات قائمة على واجهة برمجة التطبيقات (API) أو أنظمة موزعة، فإن دمج CDCT في استراتيجية الاختبار الخاصة بك سيؤدي إلى تحسين موثوقية خدماتك وقابلية التوسع.