كيف يمكنني اختبار أساليب خاصة مع DUnit?

Question

لدي الدرجة التي أنا وحدة اختبار مع DUnit.أنه يحتوي على عدد من الطرق بعض الطرق العامة و أساليب خاصة.

type
  TAuth = class(TDataModule)
  private
    procedure PrivateMethod;
  public
    procedure PublicMethod;
  end;

من أجل كتابة وحدة اختبار هذه الفئة يجب أن تجعل كل الطرق العامة.

هل هناك طريقة مختلفة للإعلان عن طرق خاصة بحيث لا يزال يمكنني اختبار لهم ولكنها ليست عامة ؟

Answer 1

وأنت لا تحتاج إلى جعلها علنية. محمية ستفعل. ثم يمكنك سلالة الطبقة لاختبار وحدة وسطح الطرق المحمية. مثال:

type
  TAuth = class(TDataModule)
  protected
    procedure MethodIWantToUnitTest;
  public
    procedure PublicMethod;
  end;

والآن يمكنك فرعي منه للاختبار وحدتك:

interface

uses
  TestFramework, Classes, AuthDM;

type
  // Test methods for class TAuthDM
  TestAuthDM = class(TTestCase)
     // stuff
  end;

  TAuthDMTester = class(TAuthDM)
  public
    procedure MethodIWantToUnitTestMadePublic;
  end;

implementation

procedure TAuthDMTester.MethodIWantToUnitTestMadePublic;
begin
  MethodIWantToUnitTest;
end;

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

Answer 2

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

  {$IfNDef TEST}
  private
  {$EndIf}

وحدة اختبار المشروع يجب أن تحدد الاختبار في project → conditional defines.من دون رؤية مواصفات تصبح نشرت.

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

  private
  {$IfDef TEST}
  public
  {$EndIf}

هذه لديها الكثير من المزايا على subclassing أو مناهج أخرى:

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

وأعتقد أنه هو حلا أوضح و أفضل من اختيار الإجابة.

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

Answer 3

أوصي "XUnit أنماط الاختبار"كتاب جيرارد Meszaros:

اختبار محددة فرعية

السؤال:كيف يمكن أن نجعل رمز قابلة للاختبار عندما نحتاج إلى الوصول إلى حالة خاصة من SUT?

الجواب:إضافة الأساليب التي تعرض الدولة أو السلوك اللازمة قبل الاختبار إلى فئة فرعية من SUT.

...إذا كان النظام تحت الاختبار (SUT) لم يكن مصممة خصيصا لتكون قابلة للاختبار, قد نجد أن الاختبار لا يمكن الحصول على الوصول إلى الدولة التي يجب أن تهيئة أو التحقق من أن في بعض نقطة في الاختبار.

المادة ما يفسر أيضا عند استخدامه و المخاطر التي ينطوي عليها.

Answer 4

ضع التعليمات البرمجية DUnit داخل الوحدة. يمكنك بعد ذلك الوصول إلى أي شيء تريد.

Answer 5

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

Answer 6

مع تمديد RTTI (دلفي 2010 أحدث), الاحتجاج طرق خاصة عبر RTTI هو خيار آخر.هذا الحل هو أيضا أعلى تصنيف في الإجابة كيف يمكنني اختبار فئة لها طرق خاصة ، الحقول أو الداخلية الطبقات ؟

Answer 7

{$IFNDEF UNITEST}
private
{$ENDIF}

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