اختبارات واجهات REST البرمجية

هناك طريقتان لإفساد اختبارات واجهة Spring Boot البرمجية، وهما أقل تشابهًا مما قد يُظن.

الأولى هي ألا نكتب أي اختبارات. لا أحد يتبنى هذا الخيار علنًا، لكن الجميع يمارسه في مرحلة ما، وعَرَضه معروف: يصبح كل تعديل مفاوضات، لأن أحدًا لا يعرف ما الذي سينكسر بسببه.

أما الثانية فهي أكثر خبثًا لأنها تبدو جادة. كل شيء مُوسَّم بـ @SpringBootTest، وكل اختبار يشغّل السياق كاملًا، وتستغرق المجموعة إحدى عشرة دقيقة، فيتوقف الفريق عن تشغيلها محليًا، وتتحقق نصف الاختبارات من أن Spring يعرف كيف يربط عنوان URL بدالة — وهو أمر تضمنه Spring أصلًا. لقد دفعنا ثمن الاختبارات دون الحصول على قيمتها: مجموعة بطيئة لم نعد نشغّلها لا تحمي من شيء.

تأتي النسبة الصحيحة من سؤال بسيط يُطرح لكل اختبار على حدة: أي شيفرة كتبتُها أنا يحميها هذا الاختبار؟ إذا كان الجواب «منطق حساب تاريخ الإرجاع»، فاختبار وحدة لا يستغرق سوى بضعة أجزاء من الثانية يكفي. وإذا كان «تسلسل البيانات والتحقق منها ورمز الحالة في وحدة التحكم لديّ»، فشريحة @WebMvcTest هي الأداة المناسبة. وإذا كان «استعلام JPQL الخاص بي يعمل على PostgreSQL»، فلا بد من PostgreSQL حقيقية، وهذا ما توفره Testcontainers.

يختبر هذا الدرس biblio-api عند كل مستوى من هذه المستويات، مع بيان ما يلتقطه الاختبار وما يتركه يمر في كل مرة.