TDD لجهاز التواصل

Question

كنت أقرأ عن TDD و ترغب في استخدامه مشروعي القادم, ولكن انا غير متأكد من كيفية هيكل دروسي مع هذا النموذج الجديد.اللغة أود أن استخدام جافا ، على الرغم من أن المشكلة ليست خاصة بلغة معينة.

المشروع

لدي بضع قطع من الأجهزة التي تأتي مع ASCII-أكثر-واجهة RS232.لا يمكن إصدار أوامر بسيطة و الحصول على استجابات بسيطة و السيطرة عليها كما لو كان من الألواح الأمامية.كل واحد له صيغ مختلفة قليلا جدا من مجموعات مختلفة من الأوامر.هدفي هو خلق فكرة مجردة/واجهة لذلك أستطيع السيطرة على كل منهم من خلال واجهة المستخدم الرسومية و/أو استدعاءات الإجراءات عن بعد.

المشكلة

أعتقد أن الخطوة الأولى هي إنشاء فئة مجردة (أنا سيئة في الأسماء ، ماذا عن 'التواصل'?) لتنفيذ جميع الاشياء مثل مسلسل I/O ثم قم بإنشاء فئة فرعية لكل جهاز.أنا متأكد من أنه سوف يكون قليلا أكثر تعقيدا من ذلك ولكن هذا هو جوهر التطبيق في ذهني.

الآن وحدة الاختبارات, أنا لا أعتقد أنني حقا بحاجة إلى الأجهزة الفعلية أو اتصال تسلسلي.ما أود القيام به هو يدي الاتصالات وهو InputStream و OutputStream (أو القارئ والكاتب) يمكن أن يكون من منفذ تسلسلي الملف ، ستدين/stdout إيصاله من اختبار وظيفة مهما كان.لذا أود فقط أن التواصل منشئ تأخذ هذه المدخلات ؟ إذا كان الأمر كذلك ، فإنه سيكون من السهل وضع بمسؤولية وضع كل شيء في إطار اختبار, ولكن الشيء الحقيقي الذي يجعل الفعلية صلة ؟ منفصلة منشئ ؟ وظيفة استدعاء منشئ مرة أخرى ؟ فئة منفصلة من العمل هو أن 'الاتصال' التواصل الصحيح I/O الأنهر ؟

تحرير

كنت على وشك كتابة مشكلة القسم من أجل الحصول على إجابات على السؤال ظننت أنني كنت أسأل, ولكن أعتقد أنني اكتشفت ذلك.كان (صحيح؟) التعرف على اثنين من المجالات الوظيفية المختلفة.

1) التعامل مع المنفذ التسلسلي

2) التواصل مع الجهاز (فهم انتاجها & توليد أوامر)

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

بعد أن يتم إجراء المزيد من البحوث على انعكاس السيطرة ، أعتقد أن لدينا وهو الجواب.منفصلة واجهة الفئة التي حل مشكلة #1 ونقله إلى منشئ الفئة(es?) أن حل مشكلة #2.بهذه الطريقة فإنه من السهل أن اختبار كل على حدة.#1 من خلال ربط إلى الأجهزة الفعلية والسماح اختبار الإطار أن تفعل أشياء مختلفة.#2 يمكن اختبارها من قبل أن يسخر من #1.

هل هذا الصوت معقول ؟ هل أنا بحاجة إلى مشاركة المزيد من المعلومات ؟

Answer 1

مع TDD ، يجب أن اسمحوا الخاص بك تصميم الظهور, ، تبدأ صغيرة, مع خطوات الطفل وتنمو فصول الاختبار قبل الاختبار, قليلا قليلا.

توضيح:تبدأ مع فئة محددة ، إلى إرسال أمر واحد ، وحدة اختبار مع نموذج أو كعب.عندما سوف تعمل بما فيه الكفاية (ربما ليس مع جميع الخيارات) ، اختبار ضد الجهاز الحقيقي مرة واحدة للتحقق من صحة وهمية/كعب/محاكاة.

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

Answer 2

آسف لكونه قليلا لينكس تتمحور ..

الطريقة المفضلة محاكاة الأدوات هو كتابة حرف برامج تشغيل الأجهزة التي تحاكي سلوكهم.هذا يتيح لك أيضا متعة القدرات ، مثل توفير ioctl() واجهة يجعل محاكاة جهاز تتصرف بشكل غير طبيعي.

في هذه النقطة ..من اختبار إلى العالم الحقيقي, لا يهم فقط وهو جهاز(ق) كنت في الواقع مفتوحة ، القراءة والكتابة.

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

Answer 3

بعد رؤية تعديلاتك أعتقد أنك العنوان بالضبط في الاتجاه الصحيح.TDD يميل إلى القيادة نحو تصميم يتكون من فصول صغيرة مع تحديد المسؤولية.وأود أيضا صدى tinkertim نصيحة - جهاز محاكاة التي يمكنك التحكم و "استفزاز" إلى التصرف بطرق مختلفة لا تقدر بثمن للاختبار.