سؤال

مع وجود التعليمات البرمجية والنماذج والبيانات داخل نفس قاعدة البيانات، أتساءل ما هي أفضل الممارسات لتصميم مجموعة من الاختبارات لتطبيق Microsoft Access (على سبيل المثال لـ Access 2007).

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

أي تجربة للمشاركة؟

هل كانت مفيدة؟

المحلول

1.اكتب كودًا قابلاً للاختبار

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

كيف تفعل ذلك؟التعرف على نموذج عرض وحدة التحكم هي بداية جيدة.

Model View Controller diagram

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

simple form with text box and button

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

Public Event OnSayHello()
Public Event AfterTextUpdate()

Public Property Let Text(value As String)
    Me.TextBox1.value = value
End Property

Public Property Get Text() As String
    Text = Me.TextBox1.value
End Property

Private Sub SayHello_Click()
    RaiseEvent OnSayHello
End Sub

Private Sub TextBox1_AfterUpdate()
    RaiseEvent AfterTextUpdate
End Sub

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

Private mText As String
Public Property Let Text(value As String)
    mText = value
End Property

Public Property Get Text() As String
    Text = mText
End Property

Public Function Reversed() As String
    Dim result As String
    Dim length As Long

    length = Len(mText)

    Dim i As Long
    For i = 0 To length - 1
        result = result + Mid(mText, (length - i), 1)
    Next i

    Reversed = result
End Function

Public Sub SayHello()
    MsgBox Reversed()
End Sub

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

Private WithEvents view As Form_Form1
Private model As MyModel

Public Sub Run()
    Set model = New MyModel
    Set view = New Form_Form1
    view.Visible = True
End Sub

Private Sub view_AfterTextUpdate()
    model.Text = view.Text
End Sub

Private Sub view_OnSayHello()
    model.SayHello
    view.Text = model.Reversed()
End Sub

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

Private controller As FormController

Public Sub Run()
    Set controller = New FormController
    controller.Run
End Sub

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

لذا، انتقل إلى الخطوة الثانية.

2.اختر إطار عمل اختبار الوحدة

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

  1. وحدة الحساب

    • يعمل فقط في الوصول.
    • يتطلب منك كتابة الاختبارات كمزيج غريب من التعليقات والتعليمات البرمجية.(لا يوجد ذكاء لجزء التعليق.
    • هناك يكون واجهة رسومية لمساعدتك في كتابة تلك الاختبارات ذات المظهر الغريب.
    • ولم يشهد المشروع أي تحديثات منذ عام 2013.
  2. وحدة VB لايتلا أستطيع أن أقول أنني استخدمته شخصيا.إنه موجود، لكن لم يتم تحديثه منذ عام 2005.

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

  4. بناء الإطار الخاص بك

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

  5. إطار اختبار وحدة الوظيفة الإضافية Ruberduck VBE
    تنصل:أنا واحد من المطورين المشاركين.

    أنا متحيز، ولكن هذا هو المفضل لدي من بين المجموعة.

    • القليل من رمز لوحة الغلاية.
    • التحسس متاح.
    • المشروع نشط.
    • وثائق أكثر من معظم هذه المشاريع.
    • وهو يعمل في معظم التطبيقات المكتبية الرئيسية، وليس فقط Access.
    • إنها، لسوء الحظ، وظيفة COM الإضافية، لذا يجب تثبيتها على جهازك.

3.البدء في كتابة الاختبارات

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

'@TestModule
Private Assert As New Rubberduck.AssertClass

'@TestMethod
Public Sub ReversedReversesCorrectly()

Arrange:
    Dim model As New MyModel
    Const original As String = "Hello"
    Const expected As String = "olleH"
    Dim actual As String

    model.Text = original

Act:
    actual = model.Reversed

Assert:
    Assert.AreEqual expected, actual

End Sub

إرشادات لكتابة الاختبارات الجيدة

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

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

نصائح أخرى

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

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

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

هذا لا يعني أنه لا يمكنك استخدام هذا بعد الآن AfterUpdate حدث!فقط ضع الكود القياسي في الحدث، مثل هذا:

Private Sub myControl_AfterUpdate()  
    CTLAfterUpdate myControl
    On Error Resume Next
    Eval ("CTLAfterUpdate_MyForm()")
    On Error GoTo 0  
End sub

أين:

  • CTLAfterUpdate هو إجراء قياسي يتم تشغيله في كل مرة يتم فيها تحديث عنصر تحكم في نموذج

  • CTLAfterUpdateMyForm هو إجراء محدد يتم تشغيله في كل مرة يتم فيها تحديث عنصر تحكم في MyForm

لدي ثم 2 وحدات.اول واحد هو

  • utilityFormEvents
    حيث سأقيم حدث CTLAfterUpdate العام الخاص بي

والثاني هو

  • MyAppFormEvents
    يحتوي على رمز محدد لجميع أشكال تطبيق MyApp ، بما في ذلك إجراء CTLafterUpDatemyForm.بالطبع ، قد لا يكون CTLafterUpDatemyForm موجودًا إذا لم يكن هناك رمز محدد لتشغيله.هذا هو السبب في أننا نقوم بتحويل "On Error" إلى "استئناف التالي" ...

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

تعد تسوية التعليمات البرمجية، حتى مع MS Access، عملية طويلة.ولكن الأمر يستحق الألم حقا!

ميزة أخرى ل الوصول هو تطبيق COM هو أنه يمكنك إنشاء تطبيق .NET لتشغيل واختبار تطبيق Access عبر الأتمتة.ميزة ذلك هي أنه يمكنك بعد ذلك استخدام إطار اختبار أكثر قوة مثل وحدة لكتابة اختبارات التأكيد التلقائية مقابل تطبيق Access.

لذلك، إذا كنت ماهرًا في لغة C# أو VB.NET مقترنة بشيء مثل NUnit، فيمكنك بسهولة إنشاء تغطية اختبار أكبر لتطبيق Access الخاص بك.

على الرغم من أن هذه إجابة قديمة جدًا:

هنالك وحدة الحساب, ، إطار عمل اختبار الوحدة المتخصص لـ Microsoft Access.

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

ما عليك سوى نسخ الكود التالي إلى وحدة التعليمات البرمجية القياسية والضغط على F5 داخل Sub لرؤيته قيد التنفيذ:

'>>> 1 + 1
'2
'>>> 3 - 1
'0
Sub DocTests()
Dim Comp As Object, i As Long, CM As Object
Dim Expr As String, ExpectedResult As Variant, TestsPassed As Long, TestsFailed As Long
Dim Evaluation As Variant
    For Each Comp In Application.VBE.ActiveVBProject.VBComponents
        Set CM = Comp.CodeModule
        For i = 1 To CM.CountOfLines
            If Left(Trim(CM.Lines(i, 1)), 4) = "'>>>" Then
                Expr = Trim(Mid(CM.Lines(i, 1), 5))
                On Error Resume Next
                Evaluation = Eval(Expr)
                If Err.Number = 2425 And Comp.Type <> 1 Then
                    'The expression you entered has a function name that ''  can't find.
                    'This is not surprising because we are not in a standard code module (Comp.Type <> 1).
                    'So we will just ignore it.
                    GoTo NextLine
                ElseIf Err.Number <> 0 Then
                    Debug.Print Err.Number, Err.Description, Expr
                    GoTo NextLine
                End If
                On Error GoTo 0
                ExpectedResult = Trim(Mid(CM.Lines(i + 1, 1), InStr(CM.Lines(i + 1, 1), "'") + 1))
                Select Case ExpectedResult
                Case "True": ExpectedResult = True
                Case "False": ExpectedResult = False
                Case "Null": ExpectedResult = Null
                End Select
                Select Case TypeName(Evaluation)
                Case "Long", "Integer", "Short", "Byte", "Single", "Double", "Decimal", "Currency"
                    ExpectedResult = Eval(ExpectedResult)
                Case "Date"
                    If IsDate(ExpectedResult) Then ExpectedResult = CDate(ExpectedResult)
                End Select
                If (Evaluation = ExpectedResult) Then
                    TestsPassed = TestsPassed + 1
                ElseIf (IsNull(Evaluation) And IsNull(ExpectedResult)) Then
                    TestsPassed = TestsPassed + 1
                Else
                    Debug.Print Comp.Name; ": "; Expr; " evaluates to: "; Evaluation; " Expected: "; ExpectedResult
                    TestsFailed = TestsFailed + 1
                End If
            End If
NextLine:
        Next i
    Next Comp
    Debug.Print "Tests passed: "; TestsPassed; " of "; TestsPassed + TestsFailed
End Sub

يؤدي نسخ التعليمات البرمجية أعلاه ولصقها وتشغيلها من الوحدة النمطية المسماة Module1 إلى ما يلي:

Module: 3 - 1 evaluates to:  2  Expected:  0 
Tests passed:  1  of  2

بعض الملاحظات السريعة:

  • ليس له أي تبعيات (عند استخدامه من داخل Access)
  • فإنه يستخدم Eval وهي وظيفة في نموذج كائن Access.Application؛هذا يعني انت استطاع استخدمه خارج Access ولكنه يتطلب إنشاء كائن Access.Application وتأهيل ملف Eval المكالمات
  • هناك بعض الخصوصيات المرتبطة Eval لتكون على علم
  • يمكن استخدامه فقط في الوظائف التي تُرجع نتيجة تناسب سطرًا واحدًا

على الرغم من حدوده، ما زلت أعتقد أنه يوفر قدرًا كبيرًا من المال مقابل أموالك.

يحرر:فيما يلي وظيفة بسيطة تحتوي على "قواعد doctest" التي يجب أن تستوفيها الوظيفة.

Public Function AddTwoValues(ByVal p1 As Variant, _
        ByVal p2 As Variant) As Variant
'>>> AddTwoValues(1,1)
'2
'>>> AddTwoValues(1,1) = 1
'False
'>>> AddTwoValues(1,Null)
'Null
'>>> IsError(AddTwoValues(1,"foo"))
'True

On Error GoTo ErrorHandler

    AddTwoValues = p1 + p2

ExitHere:
    On Error GoTo 0
    Exit Function

ErrorHandler:
    AddTwoValues = CVErr(Err.Number)
    GoTo ExitHere
End Function

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

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

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

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

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

Public Function GetOutputFolder(OutputFolder As eOutputFolder) As  FunctRet

        '///Returns a full path when provided with a target folder alias. e.g. 'temp' folder

            Dim fr As FunctRet

            Select Case OutputFolder
            Case 1
                fr.Rtn = "C:\Temp\"
                fr.Success = True
            Case 2
                fr.Rtn = TrailingSlash(Application.CurrentProject.path)
                fr.Success = True
            Case 3
                fr.EM = "Can't set custom paths – not yet implemented"
            Case Else
                fr.EM = "Unrecognised output destination requested"
            End Select

    exitproc:
        GetOutputFolder = fr

    End Function

وأوضح الكود.eOutputFolder هو مستخدم معرف Enum على النحو التالي

Public Enum eOutputFolder
    eDefaultDirectory = 1
    eAppPath = 2
    eCustomPath = 3
End Enum

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

'Type FunctRet is used as a generic means of reporting function returns
Public Type  FunctRet
    Success As Long     'Boolean flag for success, boolean not used to avoid nulls
    Rtn As Variant      'Return Value
    EM As String        'Error message
    Cmt As String       'Comments
    Origin As String    'Originating procedure/function
End Type

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

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

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

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

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

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

الوصول هو تطبيق COM.استخدم COM، وليس Windows API.لاختبار الأشياء في Access.

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

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

لقد تم إهمال صفحات الوصول إلى البيانات بواسطة MS لبعض الوقت، ولم تعمل أبدًا في المقام الأول (كانت تعتمد على تثبيت Office Widgets، وكانت تعمل فقط في IE، وكانت سيئة فقط في ذلك الوقت).

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

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

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

أو ما إذا كان هذا النوع من الاختبار الآلي صالحًا على الإطلاق أو حتى مفيدًا مع تطبيق Access.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top