تطوير واجهة المستخدم في جافا سكريبت باستخدام مبادئ TDD

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

هل من الأفضل لفصل المرئية عن الوظيفية؟ هل تقوم بتطوير العناصر المرئية أولاً ، ومن ثم كتابة اختبارات ثم ترميز وظيفة؟

0
وأضاف تحرير
الآراء: 4

7 إجابة

0
وأضاف

لقد وجدت بنية MVP لتكون مناسبة جدًا لكتابة UIs القابلة للاختبار. يمكن أن تكون فئتا المقدم و النموذج ببساطة وحدة 100٪. لا داعي للقلق بشأن العرض (الذي يجب أن يكون طبقة رقيقة ، فقط ، والتي تنشط الأحداث في مقدم العرض) لاختبار واجهة المستخدم (مع السيلينيوم وما إلى ذلك)

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

يجب أيضًا إلقاء نظرة على تقنية Presenter First TDD.

0
وأضاف

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

لقد أصدرت للتو مجموعة أدوات مفتوحة المصدر ستساعدنا في استخدام جافا سكريبت tdd بشكل كبير. وهو عبارة عن تركيبة للعديد من الأدوات مفتوحة المصدر التي تمنحك تطبيقًا ضروريًا للعمل في العمود الفقري.

يوفر أوامر فردية للتشغيل: dev web server و jasmine single browser test runner و jasmine js-test-driver multi browser test runner و sequatenization/minification for JavaScript and CSS. كما أنه يخرج إصدارًا غير محسوب من تطبيقك لتصحيح أخطاء الإنتاج ويقوم بتجميع قوالب القوالب ويدعم التدويل.

لا يوجد الإعداد مطلوب. انها تعمل فقط.

http://github.com/davidjnelson/agilejs

0
وأضاف

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

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

سأستخدم أيضًا JSCoverage للحصول على تحليل تغطية الشفرة للاختبارات. سيتم أتمتة هذا أيضًا مع السيلينيوم.

أنا حاليًا في منتصف إعداد هذا. انا تحديث هذه الإجابة مع مزيد من التفاصيل بالضبط متى أحصل على الإعداد التوصل اليه.


أدوات الاختبار:

0
وأضاف

هذا هو السبب الرئيسي الذي جعلني أتحول إلى مجموعة أدوات الويب من Google ... أقوم بالتطوير والاختبار في Java ولديك توقعات معقولة بأن جافا سكريبت المجمعة ستعمل بشكل صحيح على مجموعة متنوعة من المتصفحات. وبما أن TDD هي في الأساس وظيفة اختبار وحدة ، يمكن تطوير واختبار معظم المشروع قبل التجميع والنشر.

تكامل مجموعات الاختبارات الوظيفية والتكاملية تعمل الشفرة الناتجة كما هو متوقع بعد نشرها على خادم اختبار.

0
وأضاف

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

من وجهة نظري ، كانت وجهة النظر دائما متروكة لاختبارات قبول المستخدم لدينا (لقد كتبنا تطبيقات الويب و UATs لدينا تستخدم لغة جافا الخاصة بـ HttpUnit). ومع ذلك ، في هذا المستوى ، يعتبر اختبار التكامل بالفعل ، بدون خاصية اختبار العزل التي نرغب بها مع TDD. بسبب هذا الإعداد ، كان علينا أن نكتب اختبارات/نموذج/وحدة تحكم لدينا أولا ، ثم UI و UAT المقابلة. ومع ذلك ، في رمز واجهة المستخدم الرسومية Swing التي كنت أكتبها مؤخرًا ، كنت أقوم بكتابة كود واجهة المستخدم الرسومية أولاً باستخدام برنامج stubs لاستكشاف تصميم الواجهة الأمامية ، قبل إضافة وحدة التحكم/الطراز/واجهة برمجة التطبيقات. YMMV على الرغم من هنا.

إذا أردت أن أكرر ، فإن النصيحة الوحيدة التي يمكنني تقديمها هي ما يبدو أنك تشك بالفعل - فصل رمز واجهة المستخدم الخاص بك من المنطق قدر الإمكان و TDD لهم.

0
وأضاف

لقد فعلت بعض TDD مع جافا سكريبت في الماضي ، وما كان علي القيام به هو جعل التمييز بين اختبارات الوحدة و التكامل. سيختبر السيلينيوم موقعك بشكل عام ، مع إخراج الخادم ، ومشاركاته ، ومكالمات ajax ، وكل ذلك. ولكن بالنسبة لاختبار الوحدة ، لا شيء من هذا مهم.

ما تريده هو واجهة المستخدم التي ستتفاعل معها ونصك. الأداة التي ستستخدمها في الأساس هي JsUnit ، التي تأخذ مستند HTML ، مع بعض وظائف Javascript على الصفحة وتنفيذها في سياق الصفحة. لذا ، ما ستفعله هو تضمين HTML الذي تم فصله في الصفحة باستخدام وظائفك. من هناك ، يمكنك اختبار تفاعل النص البرمجي مع مكونات واجهة المستخدم في الوحدة المعزولة للغة HTML المجهدة والنص البرمجي والاختبارات.

قد يكون هذا مربكًا بعض الشيء لذلك لنرى ما إذا كان بإمكاننا إجراء اختبار صغير. يتيح لبعض TDD افتراض أنه بعد تحميل أحد المكونات ، يتم تلوين قائمة بالعناصر استنادًا إلى محتوى LI.

على tests.html </قوي>

<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
    
  • red
  • green
   
</body>
<script>
    function testListColor() {
        assertNotEqual( $$("#mockList li")[0].getStyle("background-color", "red") );

        var colorInst = new ColorCtrl( "mockList" );

        assertEqual( $$("#mockList li")[0].getStyle("background-color", "red") );
    }
</script>


</html>

من الواضح أن تقنية TDD هي عملية متعددة الخطوات ، لذا بالنسبة للتحكم لدينا ، سنحتاج إلى أمثلة متعددة.

yourcontrol.js (step1)

function ColorCtrl( id ) {
 /* Fail! */    
}

yourcontrol.js (step2)

function ColorCtrl( id ) {
    $$("#mockList li").forEach(function(item, index) {
        item.setStyle("backgrond-color", item.getText());
    });
    /* Success! */
}

من المحتمل أن ترى نقطة الألم هنا ، عليك أن تحافظ على هرم HTML التوضيحي هنا في الصفحة متزامنًا مع بنية ما ستكون عليه عناصر التحكم في الخادم. ولكنه يوفر لك نظامًا رائعًا لـ TDD'ing مع JavaScript.

0
وأضاف