إزاي نضمن إن المشروع شغّال زي ما العميل متوقع؟ 💯
.
.
الـ Testing مش مجرد خطوة بنعملها في الآخر "علشان نطمن"، ولا هو شوية Test Cases بنكتبهم والسلام.

الموضوع أعمق من كده بكتير...

واللي بيحدد شكله وتوقيته وطريقته هو نوع الـ Software Development Methodology اللي المشروع شغال بها.

———

📌 أولًا.. يعني إيه Software Testing؟

باختصار، الـ Testing هو الطريقة اللي بنكتشف بها الـ bugs قبل ما توصل للمستخدم.

وكمان بنقيس هل الـ software بيحقق الـ requirements ولا لا؟
هل قابل للاستخدام؟
هل بيشتغل كويس تحت الضغط؟
هل الـ UI سهل وواضح؟

كل دي أنواع مختلفة من الـ Testing...

———

📌 إزاي الـ Methodology بتأثر على الـ Testing؟

تعال نعرف الفرق...

1. الـ Waterfall Model:

في الـ Waterfall، الـ Testing بييجي في الآخر بعد ما كل حاجة تخلص.

يعني:
Requirements ➡️ Design ➡️ Development ➡️ Testing

📌 ده معناه إنك مش هتبدأ تختبر غير لما المشروع كله يكون جاهز.

وده بيخلي الـ Testing عبارة عن Quality Gate: لو الكود فيه مشاكل، بنرجع خطوة ورا، ونصلح.

⚠️ العيب هنا؟ لو فيه bug في البداية، هتكتشفه متأخر جدًا، وهتكلفك كتير.

———

2. الـ Agile Methodology:

موجود في معظم الشركات دلوقتي.

هنا بنشتغل في Sprints قصيرة، والـ Testing بيكون جزء من كل Sprint.

📌 الـ Testing بيحصل مع كل ميزة جديدة.
والـ QA بقى جزء من التيم من أول يوم.

🎯 النتيجة؟

- بتقدر تكتشف الـ Bugs بدري
- كمان تقدر تاخد Feedback من العميل بشكل مستمر علشان لو فيه تعديل
- وطبعًا التكلفة هتكون أقل

———

3. الـ DevOps / Continuous Integration:

هنا الـ testing بيكون جزء من الـ pipeline نفسها.

📌 هنا بنستخدم Tools زي Jest أو Cypress أو Selenium، وغيرها، نكتب بها Automated Tests

وأول ما الـ developer يعمل Push، الـ Tests بتشتغل أوتوماتيك.

🔥 ده بيخلي الـ Testing جزء من حياة الكود، مش خطوة منفصلة.

———

✅ لازم تبقى فاهم نوع الـ methodology اللي المشروع ماشي بها، علشان تعرف إمتى وإزاي تختبر.

✅ بلاش تعتمد بس على الـ QA، أنت كـ Developer مسؤول عن كتابة Unit Tests على الأقل.

✅ كل ما تكتب Tests أكتر، كل ما الكود بتاعك هيبقى أسهل في الـ Refactor، وأقل Bugs.

أكيد تعرف npm install أو npm i
.
.
لكن هل تعرف npm ci؟

لما تكتب npm install، هو بيبص على الـ package.json ويشوف إيه الـ packages المطلوبة، وبعدين:

- لو فيه package-lock.json بيحاول يطابقه.

- ولو مش موجود، بيبدأ يركّب اللي محتاجه ويعمل واحد جديد.

- وكمان ممكن يحدث بعض الـ packages لو شاف إن فيه إصدار أحدث متوافق مع الشروط.

وطبعًا ده كويس لكن ممكن يحصل اختلافات من جهاز للتاني...

———

الـ ci معناها "continuous integration"، والأمر ده معمول مخصوص عشان الـ automation وبيشتغل بشكل أسرع وأسهل.

- بيمسح فولدر node_modules تمامًا.

- وبعدين يركّب الـ packages بالضبط زي ما هي مكتوبة في package-lock.json.

- لو فيه فرق بين package.json و package-lock.json بيقف ويعمل Error.

✅ ده معناه إن npm ci:

- أسرع من install.

- بيعمل نفس النتائج كل مرة.

- ممتاز في الـ CI/CD pipelines أو في الشركات الكبيرة.

———

لو شغال لوحدك ولسه بتضيف/تحدث packages: استخدم npm install.

لو بتشتغل في تيم أو بتعمل Deploy على سيرفر: استخدم npm ci عشان تضمن ثبات البيئة.

💡 Claude Tip

If you're frequently switching between Sonnet and Opus, try:
/model opusplan

• This uses Opus for planning and more complex tasks while falling back to Sonnet for regular work.

• It's a useful setup when working on larger features, RFCs, architecture discussions, or multi-step tasks, while still keeping everyday interactions fast and efficient.

Ready-to-use configurations for your Claude Code projects 💯

https://www.aitmpl.com

💡 Claude Tip

Run /config, search for Output Style, and select Learning.

• Instead of giving you the full solution right away, Claude guides you step by step and asks you to write small pieces of code yourself.

• It's a great way to learn new technologies, understand unfamiliar codebases, and improve your problem-solving skills.

دردشة سريعة عن مفهوم الـ Middleware في Express.js ⚡️
.
.
لو بتشتغل بـ Node.js وبدأت تستخدم Express.js، أكيد قابلت مصطلح الـ "Middleware" في الكود... وممكن تكون عديت عليه من غير ما تفهم هو بيعمل إيه بالضبط...

تعال ندردش شوية عن إزاي الـ Middleware بيشتغل؟ وليه هو أهم جزء تقريبًا في أي تطبيق مبني بـ Express؟

———

📌 تعال نبدأ من الآخر:

الـ Express.js عبارة عن مجموعة Middleware functions ماشية في خط واحد...

يعني الـ Request بيدخل للسيرفر، بيعدي على سلسلة Middleware functions ورا بعض، وكل واحدة فيهم تقدر:

- تعدل الـ Request أو الـ Response
- توقف الـ flow
- تكمل للـ Middleware اللي بعده
- أو حتى ترجع Response للـ Client وتقفل الموضوع خالص

———

📌 يعني إيه Middleware؟

هو function بتستقبل 3 arguments:

(req, res, next)

- الـ req: الـ request اللي جاي من الـ client
- الـ res: الـ response اللي هيرجع للـ client
- الـ next: ودي function بتستخدمها علشان تنتقل للـ middleware اللي بعده

———

📌 إيه اللي هيحصل لو next مش موجودة؟

الـ request هيقف عند الـ middleware ده، والـ Express مش هيكمل لباقي الـ handlers، وهيفضل الـ client مستني response مش هيوصل أبدًا...

———

📌 أنواع الـ Middleware في Express:

1- الـ Application-level middleware

- بيتكتب بـ app.use أو app.get أو app.post... إلخ
- بيتطبق على كل أو بعض الـ routes


2- الـ Router-level middleware

- شبه الـ application-level بس بيتطبق داخل الـ Router بس
- مفيد لما يكون عندك routes كتير متقسمة


3- الـ Error-handling middleware

ده لازم يبقى له 4 arguments:

(err, req, res, next)
بيستخدم لما يكون فيه Error وعايز تتعامل معاه بطريقة أفضل


4- الـ Built-in middleware

- زي express.json أو express.static
- الـ Express بيقدمه جاهز تقدر تستخدمه على طول


5- الـ Third-party middleware

- زي morgan, cors, helmet, body-parser...
- بتسطبه بـ npm وتستخدمه علشان تضيف مميزات معينة

———

📌 الـ Request بيعدي إزاي؟

تخيل الموضوع كأنه خط إنتاج، وكل Middleware واقف على محطة بيشتغل شغلته:

Client Request
⬇️
[ Logger Middleware ]
⬇️
[ Authentication Middleware ]
⬇️
[ Validation Middleware ]
⬇️
[ Actual Route Handler ]
⬇️
Server Response

لو أي Middleware في النص قرر إنه يرجع Response بنفسه، خلاص السكة بتقف ومحدش بعده هيشتغل.

———

📌 الـ Use-cases المشهورة للـ Middleware:

- الـ Logging كل الـ requests
- التحقق من صلاحيات المستخدم (Authentication/Authorization)
- التعامل مع الـ Errors
- الـ Parsing الـ body
- الـ Setting custom headers
- الـ Rate limiting

#nodejs #backend

لو عندك سؤال في البرمجة، تقدر تبعته من خلال منصة قبيلة 💯

https://qabilah.com/profile/alisamir