مشكلة واضحة في استخدام التأكيد

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

يبدأ بحقيقة أنه نتيجة لارتكاب مؤذٍ معين ، سقط حوالي 150 اختبارًا في المشروع ، في حين أن مجموعة اختبارات السقوط لم تكن مستقرة. الاختبارات لم تكن مترابطة ، تم إجراء الاختبارات بالتسلسل. يتم استخدام قاعدة بيانات h2 في الذاكرة كمصدر بيانات للاختبارات. وقد صاحب سقوط الغالبية العظمى من هذه الاختبارات الـ 150 خطأ في السجل: "لا يمكن الحصول على اتصال ، خطأ تجمع مهلة في انتظار كائن خامل". يجب أن يقال أن حجم تجمع الاتصال عند إجراء الاختبارات في المشروع هو 1.

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

TransactionRunner.run(dbDataManager(), new MethodTransaction() { @Override public ExecutionResult runInTransaction() throws Exception { // ,       return result; } ); 

نتيجة للتحليل ، تم الكشف عن أن الخطأ يبدأ في الظهور بعد اختبار فاشل يحتوي على استدعاء رمز في معاملة:

 TransactionRunner.run(dbDataManager(), new MethodTransaction() { @Override public ExecutionResult runInTransaction() throws Exception { // ...   // assert   assert( 1, result.getSomeNotEqualOneIntValue() ); return result; } ); 

ألق نظرة داخل فئة TransactionRunner ، يؤدي استدعاء الأسلوب إلى الرمز التالي:

 protected ExecutionResult run() throws CommonException { Transaction outerTr = getThreadTransaction(); bindThreadTransaction(null); try { beginTransaction(); try { setResult(transactionCode.runInTransaction()); } catch (Exception e) { dbDataManager().rollbackTransaction(); if (transaction.onException(this, e)) throw e; } dbDataManager().commitTransaction(); return getResult(); } catch (Exception e) { throw ExceptionUtil.createCommonException(e); } finally { bindThreadTransaction(outerTr); } } 

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

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

بدت لي القضية جديرة بالتثبيت ، ربما هذه التجربة مفيدة لشخص ما.