🤦🏻 🍧 🌻 كيفية جعل سيارة اختبارات الكتابة من التعليمات البرمجية لك 🧚🏼 🖐🏻 🔌

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

تريد Julia Volkova اختبار الفكرة في الواقع وتحاول تحويل إنشاء الاختبارات استنادًا إلى التعليمات البرمجية إلى آلة ، دون استخدام تعليمات أو عقود إضافية. ستخبرك جوليا عن الاكتشافات التي تجلبها الرحلة إلى عالم البرمجة التخطيطية ، AST ، التحليل والتحليل ، وما سمح لنا كل هذا بتحقيقه في إنشاء الاختبارات تلقائيًا ، في موسكو Python Conf ++. في غضون ذلك ، سألت من أين جاءت الفكرة - لأتمتة الاختبار ، وما هو أساس النموذج الأولي وما الذي يجب القيام به.

جوليا فولكوفا (xnuinside) مطور Python أول في GridDynamics. في وقت فراغه يكتب مشاريع الحيوانات الأليفة ، والتي تجد في بعض الأحيان التطبيق في الحياة الحقيقية. لذلك ، مرارا وتكرارا اختبار الرمز القديم ، لاحظت جوليا أنه يمكن القيام بالعديد من الأشياء تلقائيًا. بالطبع ، فهم الشفرة وكتابة الاختبارات "الصحيحة" لها في بعض الأحيان يكون صعبًا جدًا بالنسبة لمطور حي ذو خبرة. لكن الأتمتة يمكنها القيام بالكثير من الاختبارات البسيطة وإعداد قاعدة التعليمات البرمجية ، والتي سيتمكن المطور من تعديلها حسب تقديره.

- لنبدأ بالمريض نفسه ، لماذا تعتقد أن الناس لا يكتبون الاختبارات؟ يقول الأشخاص الأذكياء لكتابة الاختبارات ، لكنهم لا يزالون لا يكتبون. لماذا توجد مثل هذه المشكلة؟

- أعتقد أن هناك عدة أسباب. أولا ، معظمنا كسالى في الطبيعة. قليل من الناس يحبون مباشرة كتابة الاختبارات - يستيقظون في الصباح ويقولون: "يجب أن نبدأ اليوم بـ 15 اختبارًا ، وإلا فسيكون كل شيء سيئًا ، ولكن في نفس الوقت لن تنجح حياتي". يتجلى الكسل الطبيعي في كثير من الأحيان ، خاصة عندما ترى أن الطريقة ليست مثيرة للاهتمام للغاية ، فهي تحتوي على كود واضح ، ولكنك لا تزال بحاجة إلى تغطيتها بالاختبارات.

قليل من كتابة TDD ، لذلك ليس عليك فقط كتابة اختبار ، بل عليك أيضًا قضاء بعض الوقت على الشفرة.

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

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

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

"إذا لم تذهب إلى مثل هذا التطرف ، ما رأيك ، من يجب أن يكتب الاختبارات؟" هل يجب أن يكون المبرمج نفسه ، المبتدئ ، أو على العكس ، أروع مطور في الفريق؟

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

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

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

- يمكننا القول أن المشكلة تكمن في أن الناس لديهم فكرة سيئة عن كيفية سير عملية تطوير البرمجيات؟

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

ليس من الصحيح دائمًا القول أن الشخص الذي لا يحب الاختبارات هو مطور غير ماهر.

لديه بعض الرؤية الخاصة به ، وليس لي أن أحكم. ما زلت ألتقي بمطوري البرامج الذين يكتبون كودًا لمدة 10 سنوات ويقولون أنه من الضروري تغطية كل شيء باختبارات الوحدة ، واختبارات الدخان الكافية وعمل ضمان الجودة.

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

- هل تعتقد أن Python تمت كتابتها بشكل ديناميكي ولا تحقق أي شيء في مرحلة التجميع؟ هل يمكن أن يكون أسهل في لغات أخرى مع هذا؟

- أعتقد ، يلعب ، وقوي. هذه قصة أبدية عن الأنواع ، ولكن مع ظهور التعليقات التوضيحية من النوع ، أصبح من السهل العمل معها.

على سبيل المثال ، في Python ، قد تكون هناك سلاسل من الوظائف المتداخلة ، حيث يتحول المتوقع في نهاية القائمة لسبب ما إلى قاموس. قد لا يصل التنفيذ إلى الوظيفة النهائية أبدًا ، ولكن في بعض الحالات ، في حالة استثنائية ، ثم سيظهر خطأ.

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

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

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

لكن هذا غير ممكن في معظم المشاريع التي شاركت فيها. لأن المشروع يحتوي أيضًا على محللي بيانات يقولون ذلك لأنهم يكتبون بلغة Python لأنهم لا يريدون العبث بالأنواع ، فهو ملائم لهم.

يعتقد عدد كبير من الناس أنه بالإضافة إلى Python في غياب الأنواع والكتابة.

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

- وأنا أتفق معك تماما في هذا الشأن. يبقى فقط لفهم كيفية استخدام الأنواع ، لأن هذا موضوع غامض منفصل.

: «, Haskell , : , . Python , , ».

— . , , legacy- smoke-. . ?

- لن أقول أن نهجي أفضل ، إنه مختلف فقط. إن تغطية الرمز الخاص بك باختبارات الدخان أمر جيد عندما تستطيع. كان مشروعي السابق هو الألم الجوهري المرتبط بالاختبارات. كان عبارة عن منصة لعلوم البيانات من 8 خدمات صغيرة و 20 ألف سطر من التعليمات البرمجية. تكمن المشكلة في أن النظام الأساسي يتلقى كمية كبيرة من البيانات والخصائص للمركبات والمحطات والمدن ، ومواقف السيارات المختلفة وأنواع الإمدادات ، ويجمع ويخلق مجموعة ضخمة من الجداول الزمنية المحتملة لهذه المركبات في جميع أنحاء العالم. يأخذ الجدول الزمني في الاعتبار عددًا كبيرًا من الشروط من الفئة حيث يمكنك إعادة تزويد السيارة بالوقود ، حيث تتوقف مؤقتًا.

هناك العديد من الطرق المختلفة في النظام التي يمكن استخدامها في مواقف 1-2 ، والتي ربما لن يتذكرها أي من العملاء. ثم تتحول كتابة اختبارات الدخان في الواقع إلى اختبارات كتابة للنظام بأكمله ، مع مراعاة جميع الوظائف ومجموعاتها.

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

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

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

سوف أعطي مثالا على ذلك. هناك وظيفة صغيرة تأخذ قاموسًا ، منها بعض القيمة والمفتاح. هذا المفتاح مهم للغاية للأعمال التجارية ، ولكن من وجهة نظر الكود فهو عملية بدائية نوعًا ما: خذ من القاموس ، حتى لو كان مفتاحًا مدمجًا بضع مرات ؛ تحقق من أنه هناك ، وأنه ليس صفرًا ؛ قم بتبديلها أو ربما فقط إرجاع القيمة. هذا رمز بدائي إلى حد ما من وجهة نظر AST. لا أريد أن أضيع وقتي عليه وكتابة الاختبارات. أريد أن تقوم السيارة بذلك من أجلي.

هذا هو بالضبط metaprogram مع رمز إدخال وكود الإخراج. دعنا نقول لوحدة py ، التي تقول: "هنا لدي تأكيد ،" ساعدتك "أن هناك أخطاء بارزة في هذه الحالة ، وقيم صحيحة تعود في مثل هذه الحالة ، وشيء آخر حدث مع مثل هذه الحجة" . هذا ، في الواقع ، يقوم بالعمل حيث أنظر بنفسي إلى ما يتم تغذيته لإدخال الوظيفة وكتابتها في الاختبار.

أريد أن يولِّد البرنامج الحد الأدنى الذي يمكنه تشغيله لي. ولكن يجب أن يكون هذا ملف اختبار ، حيث يمكنك ، إذا رغبت ، تغيير أو توسيع شيء ما. التي يمكنك القيام بها في Git ، اختبار الاختبار ، إلخ.

- كم يمكنك الاعتماد على هذه الاختبارات التي يتم إنشاؤها تلقائيًا؟ ماذا أعني - ما مدى ارتباطها بتنفيذ معين ، وكيف سيتصرفون في ظل التغييرات العادية في منطق الأعمال أو إعادة البناء؟

- الفكرة هي أخذ الكود بالشكل الذي هو عليه الآن ، واستناداً إليه لإنشاء اختبارات صالحة في الوقت الحالي.

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

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

أريد الحصول على أداة للمطور ، وليس قطعة لزيادة تغطية الرمز.

- ماذا يمكن أن تكون مقاييس النجاح؟ كيف نفهم أننا أنشأنا الاختبارات بشكل جيد؟

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

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

- أخبرني كم هو صعب القيام به من الناحية الفنية. تبدو مهمة صعبة للغاية.

نعم ، هذه مهمة صعبة للغاية ، وربما هذه الحقيقة والعديد من الظروف الأخرى هي التي دفعتني للحديث عن هذا في تقرير عن موسكو Python Conf ++. أريد أن أطرح هذا الموضوع وأهتم بالناس الآخرين وأناقش الحلول معهم.

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

لفهم مدى صعوبة هذا ، دعونا نتذكر كيف يعمل المترجم. هناك عمليات ، عبارات في الكود ، يقوم بها المترجم - جيد ، غير جيد ، فاشل ، لم يفشل - وينتج النتيجة. علاوة على ذلك ، يضيف المطور يدويًا حججًا جديدة ، ويبدأ المترجم مرة أخرى ، ويتأكد من نجاح كل شيء الآن. ولكن عندما تحاول إنشاء اختبارات للرمز ، فأنت بحاجة أولاً إلى المرور عبر شجرة AST وفهم الخطوات التي عليك اتخاذها للحصول على النتيجة.

يمكن أن تحتوي الوظيفة على العديد من مجموعات الحجج ، واستراتيجيات الحجج ، والعديد من النتائج لهذه الاستراتيجيات. بالحديث عن الإستراتيجيات ، أعني ذلك ، دعنا نقول ، هناك if arg_1==1: raise error. هذا يعني أن هناك بعض المجموعات arg_1=1التي تقوم الدالة دائمًا بإرجاع خطأ لها. ولكن مع الجدل ، ستكون arg_1>2نتيجة الوظيفة مختلفة ، وسيتم إنشاء مجموعة ثانية ، والاستراتيجية الثانية.

وبناءً على ذلك ، نحتاج إلى العثور على كل مجموعات الحجج وإبرازها (إذا كانت موجودة بالطبع) ، حيث تغير الوظيفة سلوكها. ثم اتبع سلسلة الإجراءات: ماذا سيحدث داخل الوظيفة بهذه الحجج للحصول على النتيجة النهائية.

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

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

لا أعتقد أنه في يوم من الأيام سيكون من الممكن تغطية 100٪ من جميع أنواع الحالات تلقائيًا ، على سبيل المثال ، للوحات ضخمة من رموز مصدر Django. إنه شاق ولكنه مثير للاهتمام. حتى الآن أشعر بالفضول حيث لدي الصبر والقوة للوصول.

- هل هناك أمثلة من لغات ومناطق أخرى حيث يعمل شيء مثل هذا؟

- لا توجد مثل هذه معروفة. أعتقد أنه من الأسهل كتابة اختبار بدلاً من قطع أداة خاصة.

ولكن لدي شعور بأننا سنقوم عاجلاً أم آجلاً بما نقوم به بالفعل بشكل جيد.

هناك مجموعة كبيرة من المطورين الذين يكتبون اختبارات الوحدة جيدًا. لدينا كفاءات كافية في تطوير Python لنرغب في كتابة أداة أو مكتبة تقوم بذلك لنا. وسنكتب أشياء أكثر تعقيدًا واختبارات أكثر تعقيدًا.

هناك نوع من توليد الاختبار في Java و C و. net. ولكن هناك أيضًا كل شيء يعتمد على الممتلكات أو العقود. في لغة C ، يوجد جيل اختبار لكل حرف على حدة ، يبدو أنه ينظر فقط إلى الكود وعلى أساس هذا يقوم ببعض الاختبارات. لكن هذا مستوى مختلف من التجريد في اللغة نفسها لدرجة أنني لست متأكدًا مما إذا كانت هذه قصة مماثلة.

إذا كان هناك شيء مشابه جدًا ، فيمكن بالطبع تبني شيء ما ، نظرة خاطفة.

- هل تعتقد أن الأطر أو ربما تقنيات لكتابة كود Python تبسط أو تعقد مهمة توليد الاختبارات من شجرة AST؟

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

- ربما يكون نوعًا من التقنية - الكثير من الديناميكيات ، استخدام getattr - شيء من هذا القبيل؟ أم أنها تعمل بشكل جيد؟

"إنه يعمل بشكل جيد تمامًا." لأن getattr أو التلاعب باستخدام metaclasses مرئية في AST. نعم ، يجب حلها ، وهذا يضيف بعض التعقيد. ولكن يتم تعقب هذا على أي حال.

- لقد قلنا بالفعل أن الاختبارات التي يتم إنشاؤها تلقائيًا مخصصة في المقام الأول للأشخاص. ما مدى سهولة قراءتهم للناس؟ سيكون هناك الكثير من المنطق داخل كل اختبار ، أؤكد؟ كيف سيبدو الفصل بين الكود والبيانات ، كيف ترى ذلك؟

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

تأكيدات حتى الآن مجتمعة في طريقة واحدة. أي أنه إذا كانت هناك وظيفة وهناك 5 حالات نريد التحقق منها ، فحينئذٍ حتى تدخل 5 تأكيدات داخل الوظيفة.

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

- هل تؤيد unittest أو pytest؟

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

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

- ما مدى ارتباط هذا النهج بالاختبارات القائمة على الممتلكات؟

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

- هل تخطط لدعم برمجة العقود أو فصلها بطريقة أو بأخرى بطريقة خاصة؟ لأنه يساعد كثيرًا في العمل مع اختبار الوحدة ، والاختبار القائم على الممتلكات ، والاختبارات ، من حيث المبدأ ، لفهم منطق الأعمال.

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

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

إذا كان من الممكن تعديل الرمز ، فإن اختبارات العقد جيدة.

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

- أخبرنا عن النقطة المهمة التالية: كيفية اختبار الاختبارات المستلمة وكم يمكنك أن تضمن أن هذه الاختبارات تختبر شيئًا حقًا؟

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

- دعنا نناقش الآن مؤتمر Python Conf ++ في موسكو قليلاً. ونحن سوف أداءذكرنا أحد مطوري الفرضيات عدة مرات. ما الذي يهمك أن تسأله؟

- سأكون مهتمًا بسؤال زاك عن المكان الذي يرغبون في تطوير المشروع فيه مع المشرفين: ما الذي يجب إضافته ، وأي طريقة للتطوير. أعلم بالتأكيد أن Zach لديه الآن علاقات عامة لتوليد الاختبار. يفعلون ذلك بانتظام. بتعبير أدق ، يضيف الديكور إلى اختبارات الوحدة الحالية.

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

"نحن نعتمد على هذا عندما نقوم بإعداد برنامج المؤتمر: للتقارير لتحديد مواضيع للمناقشة ، حيث يمكن للجميع العثور على أفكار واتجاهات جديدة للتنمية. ما التقارير التي ستذهب إليها؟

- أود أن أزعجني وأذهب إلى جميع التقارير الساعة 12 ظهرا. في هذا الوقت ، سيكون هناك Zac Hatfield-Dodds ، و Andrey Svetlov مع تقرير عن البرمجة غير المتزامنة ، و Vladimir Protasov مع إعادة التشغيل الآلي . سأذهب إلى واحد من آخر اثنين ، ثم سأركض إلى Zach في نهاية التقرير ( ملاحظة المحرر: خذ عملية اختراق في الخدمة - استمع تمامًا إلى الموضوع الجديد ، ويأتي إلى نهاية التقرير والأسئلة للمتحدث الذي تريد التحدث إليه ) .

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

- أخبرني أكثر قليلاً عن موضوع تقريرك ، لماذا تفعل ، ماذا تفعل ، لماذا تتحدث وماذا تنتظر من الخطاب؟

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

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

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

- أين تأخذ الوقت للتحدث في المؤتمرات وكتابة مكتباتك الخاصة؟ هذا السؤال ينبثق باستمرار في الواقع ، ويشكو الكثير من الناس من أنه ليس لديهم الوقت لأي شيء.

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

أحاول ألا أقوم بعمل غير ضروري في العمل ، ولا أفعل ما يستتبعه فقدان وقتي بعد ذلك.

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

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

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

لذلك ، ربما لدي الوقت. لأنني أحاول تحسين وقت عملي ، لجعل الأمر يستغرق عددًا معينًا من الساعات لإكمال المهمة. في الوقت نفسه ، أفهم أنه في الهيكل الجيد يجب أن يكون هناك ساعة أو ساعتين للديون الفنية وبعض التحسينات.

لن أقول أنني أعمل 8 ساعات دون النهوض. سوف أنظر إلى مطور يجلس ويكتب الرمز لمدة 8 ساعات من وقت العمل. إذا كنت تأخذ يوم العمل المعتاد ، فإن ساعتين فقط هي جميع أنواع الاختبارات ، ومراجعة الكود ، والديون الفنية ، و "الطنانة" على الكود. ساعات 3 هي حل للمشاكل الحالية ، ساعة للتواصل مع المديرين. والساعتان المتبقيتان موزعتان لسبب ما ، للمناقشة مع الفرق والأشياء المستقلة.

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

لا يوجد سر ، ما عليك سوى القيام بما تريد ، ولكن في نفس الوقت دون الإضرار بمن حولك والمشروع.

للحصول على تفاصيل حول تنفيذ إنشاء اختبار من كود Python ، بالإضافة إلى حل العديد من المهام الأخرى لمطور Python ، قم بزيارة موسكو Python Conf ++ ، التي قمنا بتأجيلها إلى 15 سبتمبر.

كيفية جعل سيارة اختبارات الكتابة من التعليمات البرمجية لك

More articles: