https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/Recent content in أساسيات الاختبار on تعلّم Go بالاختباراتHugoarhttps://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/intro-to-acceptance-tests/Mon, 01 Jan 0001 00:00:00 +0000https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/intro-to-acceptance-tests/<h1 id="مقدمة-إلى-اختبارات-القبول">مقدمة إلى اختبارات القبول<a class="anchor" href="#%d9%85%d9%82%d8%af%d9%85%d8%a9-%d8%a5%d9%84%d9%89-%d8%a7%d8%ae%d8%aa%d8%a8%d8%a7%d8%b1%d8%a7%d8%aa-%d8%a7%d9%84%d9%82%d8%a8%d9%88%d9%84"></a></h1> <p>في <code>$WORK</code>، كنا نواجه حاجة متكررة إلى &ldquo;الإيقاف الرشيق&rdquo; (graceful shutdown) لخدماتنا. فالإيقاف الرشيق يضمن أن نظامك يُنهي عمله كما ينبغي قبل إنهائه. ومثال من الحياة الواقعية: شخص يحاول إنهاء مكالمة هاتفية على نحو لائق قبل الانتقال إلى الاجتماع التالي، بدلًا من إغلاقها في منتصف الجملة.</p> <p>سيقدّم هذا الفصل مقدمة عن الإيقاف الرشيق في سياق خادم HTTP، وعن كيفية كتابة &ldquo;اختبارات القبول&rdquo; (acceptance tests) لتمنح نفسك ثقة في سلوك كودك.</p>https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/scaling-acceptance-tests/Mon, 01 Jan 0001 00:00:00 +0000https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/scaling-acceptance-tests/<h1 id="توسيع-نطاق-اختبارات-القبول">توسيع نطاق اختبارات القبول<a class="anchor" href="#%d8%aa%d9%88%d8%b3%d9%8a%d8%b9-%d9%86%d8%b7%d8%a7%d9%82-%d8%a7%d8%ae%d8%aa%d8%a8%d8%a7%d8%b1%d8%a7%d8%aa-%d8%a7%d9%84%d9%82%d8%a8%d9%88%d9%84"></a></h1> <p>هذا الفصل تكملة لفصل <a href="https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/intro-to-acceptance-tests/">مقدمة إلى اختبارات القبول</a>. ويمكنك العثور على <a href="https://github.com/quii/go-specs-greet">كود هذا الفصل النهائي على GitHub</a>.</p> <p>اختبارات القبول ضرورية، وهي تؤثر تأثيرًا مباشرًا في قدرتك على تطوير نظامك بثقة عبر الزمن، وبكلفة تغيير معقولة.</p> <p>وهي أيضًا أداة بديعة تساعدك في التعامل مع الكود القديم (legacy code). فحين تواجه قاعدة كود ضعيفة بلا أي اختبارات، قاوم الرغبة في البدء بإعادة الهيكلة. واكتب بدلًا من ذلك بعض اختبارات القبول لتصنع لنفسك شبكة أمان تتيح لك تغيير داخل النظام بحرية دون التأثير في سلوكه الخارجي الوظيفي. فاختبارات القبول لا تهتم بالجودة الداخلية، لذا فهي مناسبة جدًا لهذه المواقف.</p>https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/working-without-mocks/Mon, 01 Jan 0001 00:00:00 +0000https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/working-without-mocks/<h1 id="العمل-بدون-الـ-mocks-والـ-stubs-والـ-spies">العمل بدون الـ Mocks والـ Stubs والـ Spies<a class="anchor" href="#%d8%a7%d9%84%d8%b9%d9%85%d9%84-%d8%a8%d8%af%d9%88%d9%86-%d8%a7%d9%84%d9%80-mocks-%d9%88%d8%a7%d9%84%d9%80-stubs-%d9%88%d8%a7%d9%84%d9%80-spies"></a></h1> <p>يتعمّق هذا الفصل في عالم الـ test doubles، ويستكشف كيف تؤثر في عملية الاختبار والتطوير. سنكشف حدود الـ mocks والـ stubs والـ spies التقليدية، ثم نقدّم نهجًا أكثر كفاءة وقابلية للتكيّف باستخدام الـ fakes والـ contracts.</p> <h2 id="باختصار">باختصار<a class="anchor" href="#%d8%a8%d8%a7%d8%ae%d8%aa%d8%b5%d8%a7%d8%b1"></a></h2> <ul> <li>الـ Mocks والـ spies والـ stubs تشجعك على ترميز افتراضاتك حول سلوك اعتمادياتك بشكل ارتجالي (ad-hoc) في كل اختبار.</li> <li>وهذه الافتراضات لا يُتحقق منها عادةً إلا يدويًا، ما يهدد فائدة مجموعة اختباراتك.</li> <li>أما الـ fakes والـ contracts فتمنحاننا طريقة أكثر استدامة لإنشاء test doubles بافتراضات مُتحقق منها، وبإعادة استخدام أفضل من البدائل الأخرى.</li> </ul> <p>هذا الفصل أطول من المعتاد، فلنأخذ نفسًا قصيرًا، ابدأ باستكشاف <a href="https://github.com/quii/go-fakes-and-contracts">مستودع الأمثلة</a>. وبالأخص، ألقِ نظرة على <a href="https://github.com/quii/go-fakes-and-contracts/blob/main/domain/planner/planner_test.go">اختبار planner</a>.</p>https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/refactoring-checklist/Mon, 01 Jan 0001 00:00:00 +0000https://zeyadsleem.github.io/learn-go-with-tests-ar/docs/testing-fundamentals/refactoring-checklist/<h1 id="خطوة-إعادة-الهيكلة-قائمة-تحقق-البداية">خطوة إعادة الهيكلة، قائمة تحقق البداية<a class="anchor" href="#%d8%ae%d8%b7%d9%88%d8%a9-%d8%a5%d8%b9%d8%a7%d8%af%d8%a9-%d8%a7%d9%84%d9%87%d9%8a%d9%83%d9%84%d8%a9-%d9%82%d8%a7%d8%a6%d9%85%d8%a9-%d8%aa%d8%ad%d9%82%d9%82-%d8%a7%d9%84%d8%a8%d8%af%d8%a7%d9%8a%d8%a9"></a></h1> <p>إعادة الهيكلة (refactoring) مهارة تصبح، بفعل التدريب الكافي، طبيعة ثانية سهلة في معظم الحالات.</p> <p>وكثيرًا ما يُخلط بين هذا النشاط وتغييرات تصميمية أكبر، لكنهما منفصلان. والتمييز بين إعادة الهيكلة وغيرها من أنشطة البرمجة مفيد لأنه يتيح لي العمل بوضوح وانضباط.</p> <h2 id="إعادة-الهيكلة-مقابل-أنشطة-أخرى">إعادة الهيكلة مقابل أنشطة أخرى<a class="anchor" href="#%d8%a5%d8%b9%d8%a7%d8%af%d8%a9-%d8%a7%d9%84%d9%87%d9%8a%d9%83%d9%84%d8%a9-%d9%85%d9%82%d8%a7%d8%a8%d9%84-%d8%a3%d9%86%d8%b4%d8%b7%d8%a9-%d8%a3%d8%ae%d8%b1%d9%89"></a></h2> <p>إعادة الهيكلة ليست سوى تحسين للكود الموجود <u>دون تغيير السلوك</u>؛ ولذلك لا ينبغي أن تضطر الاختبارات إلى التغيير.</p> <p>ولهذا فهي الخطوة الثالثة في دورة التطوير الموجه بالاختبار (TDD). فبعد أن تضيف سلوكًا واختبارًا يسنده، ينبغي أن تكون إعادة الهيكلة نشاطًا لا يتطلب أي تغيير في كود اختبارك. <strong>أنت تفعل شيئًا آخر</strong> إذا كنت &ldquo;تعيد هيكلة&rdquo; كود ما وتضطر إلى تغيير الاختبارات في الوقت نفسه.</p>