MS Access 애플리케이션을 테스트하는 가장 좋은 방법은 무엇입니까?

https://stackoverflow.com/questions/47400

09-06-2019
|

문제

동일한 데이터베이스 내의 코드, 양식 및 데이터를 사용하여 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

그럼 그거 정말 대단하고 다 좋은데 그런데 그게 테스트와 무슨 상관이 있는 걸까요?! 친구야, 그랬지 모든 것 테스트와 관련이 있습니다.우리가 한 일은 코드를 만드는 것입니다. 테스트 가능.제가 제공한 예에서는 GUI를 테스트하려고 시도할 이유가 전혀 없습니다.우리가 실제로 테스트해야 할 유일한 것은 model.실제 논리가 모두 여기에 있습니다.

그럼 2단계로 넘어갑니다.

2.단위 테스트 프레임워크 선택

여기에는 많은 옵션이 없습니다.대부분의 프레임워크에는 COM 추가 기능 설치, 많은 보일러 플레이트, 이상한 구문, 주석으로 테스트 작성 등이 필요합니다.그래서 내가 참여하게 됐지 나 자신을 구축, 따라서 내 답변의 이 부분은 공정하지 않지만 사용 가능한 항목에 대한 공정한 요약을 제공하려고 노력하겠습니다.

AccUnit
- Access에서만 작동합니다.
- 주석과 코드를 이상하게 혼합하여 테스트를 작성해야 합니다.(주석 부분에는 인텔리센스가 없습니다.
- 거기 ~이다 하지만 이상하게 보이는 테스트를 작성하는 데 도움이 되는 그래픽 인터페이스입니다.
- 이 프로젝트는 2013년 이후 업데이트가 없습니다.
VB 라이트 유닛개인적으로 사용했다고는 말할 수 없습니다.거기에 있지만 2005년 이후로 업데이트가 나타나지 않았습니다.
xl단위xlUnit은 나쁘지는 않지만 좋지도 않습니다.투박하고 보일러 플레이트 코드가 많이 있습니다.최악 중의 최고이지만 Access에서는 작동하지 않습니다.그래서 그것은 끝났습니다.
자신만의 프레임워크 구축

나는 거기 가서 그걸 했어.아마도 대부분의 사람들이 원하는 것 이상일 것입니다. 그러나 네이티브 VBA 코드로 단위 테스트 프레임워크를 구축하는 것은 완전히 가능합니다.
Rubberduck VBE 추가 기능의 단위 테스트 프레임워크
부인 성명:나는 공동 개발자 중 한 명이에요.

나는 편견이 있지만 이것은 지금까지 내가 가장 좋아하는 것입니다.
- 보일러 플레이트 코드가 거의 또는 전혀 없습니다.
- 인텔리센스를 사용할 수 있습니다.
- 프로젝트가 활성화되어 있습니다.
- 대부분의 프로젝트보다 문서가 더 많습니다.
- Access뿐만 아니라 대부분의 주요 사무용 응용 프로그램에서 작동합니다.
- 안타깝게도 COM 추가 기능이므로 컴퓨터에 설치해야 합니다.

삼.테스트 작성 시작

이제 섹션 1의 코드로 돌아갑니다.우리가 사용하는 유일한 코드 정말 테스트에 필요한 것은 MyModel.Reversed() 기능.그럼, 그 테스트가 어떤 모습일지 살펴보겠습니다.(주어진 예에서는 Rubberduck을 사용하지만 이는 간단한 테스트이므로 선택한 프레임워크로 변환할 수 있습니다.)

'@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

좋은 테스트 작성을 위한 지침

한 번에 하나만 테스트하십시오.
좋은 테스트는 시스템에 버그가 있거나 요구 사항이 변경된 경우에만 실패합니다.
데이터베이스 및 파일 시스템과 같은 외부 종속성을 포함하지 마세요.이러한 외부 종속성으로 인해 통제할 수 없는 이유로 테스트가 실패할 수 있습니다.둘째, 테스트 속도가 느려집니다.테스트가 느리면 실행하지 않을 것입니다.
테스트 대상을 설명하는 테스트 이름을 사용하십시오.내용이 길어지더라도 걱정하지 마세요.설명하는 것이 가장 중요합니다.

그 답변이 조금 길고 늦었다는 것을 알고 있지만 일부 사람들이 VBA 코드에 대한 단위 테스트 작성을 시작하는 데 도움이 되기를 바랍니다.

다른 팁

나는 Knox와 David의 답변에 감사드립니다.내 대답은 그들 사이 어딘가에 있을 것이다.그냥 만들어 디버깅할 필요가 없는 양식!

폼은 기본적으로 그래픽 인터페이스를 의미하는 그대로만 사용해야 한다고 생각합니다. 오직, 여기서는 디버깅할 필요가 없다는 의미입니다!그러면 디버깅 작업이 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
모든 특정 양식의 MITAPP 응용 프로그램의 특정 코드를 포함하고 CTLAFTERUPDATEMYFORM 절차를 포함합니다.물론, 특정 코드가 실행되지 않으면 CTLAFTERUPDATEMYFORM이 존재하지 않을 수 있습니다.이것이 우리가 "on error"를 "다음에 이력서"로 돌리는 이유입니다.

이러한 일반적인 솔루션을 선택하는 것은 많은 의미를 갖습니다.이는 높은 수준의 코드 정규화(코드를 쉽게 유지 관리할 수 있음을 의미)에 도달했음을 의미합니다.그리고 양식별 코드가 없다는 것은 양식 모듈이 완전히 표준화되어 생산이 가능하다는 의미이기도 합니다. 자동화된:양식/컨트롤 수준에서 관리하려는 이벤트를 말하고 일반/특정 절차 용어를 정의하면 됩니다.
자동화 코드를 한번에 작성해 보세요.
며칠의 작업이 필요하지만 흥미로운 결과를 얻을 수 있습니다.나는 지난 2년 동안 이 솔루션을 사용해 왔으며 이 솔루션이 확실히 올바른 솔루션이었습니다.내 양식은 "컨트롤 테이블"에 연결된 "양식 테이블"을 사용하여 처음부터 완전히 자동으로 생성됩니다.
그런 다음 양식의 특정 절차를 수행하는 데 시간을 보낼 수 있습니다.

MS Access를 사용하더라도 코드 정규화는 오랜 과정입니다.하지만 정말 고통을 겪을 만한 가치가 있는 일입니다!

또 다른 장점 COM 응용 프로그램인 액세스 당신이 만들 수 있다는 것입니다 자동화를 통해 Access 애플리케이션을 실행하고 테스트하는 .NET 애플리케이션.이것의 장점은 다음과 같은 보다 강력한 테스트 프레임워크를 사용할 수 있다는 것입니다. NUnit Access 앱에 대한 자동화된 어설션 테스트를 작성합니다.

따라서 NUnit과 결합된 C# 또는 VB.NET에 능숙하다면 Access 앱에 대한 더 큰 테스트 적용 범위를 더 쉽게 만들 수 있습니다.

그것은 매우 오래된 답변이지만 :

있다 AccUnit, Microsoft Access용 특수 단위 테스트 프레임워크입니다.

나는 한 페이지를 꺼냈다 파이썬의 doctest Access VBA에서 DocTests 프로시저를 개념화하고 구현했습니다.이것은 분명히 완전한 단위 테스트 솔루션은 아닙니다.아직은 상대적으로 어려서 모든 버그를 해결했는지는 의문이지만, 야생에 출시할 만큼 충분히 성숙했다고 생각합니다.

다음 코드를 표준 코드 모듈에 복사하고 Sub 내부에서 F5를 누르면 실제로 작동하는 것을 볼 수 있습니다.

'>>> 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 세트를 실행한 다음 출력을 확인하고 출력이 좋은지 비교합니다.이 접근 방식은 분명히 GUI를 테스트하지 않으므로 수동으로 실행되는 일련의 테스트 스크립트(여기서는 열린 양식 1을 말하고 컨트롤 1을 클릭하는 단어 문서와 같은 것을 의미함)를 사용하여 테스트를 강화할 수 있습니다.

테스트 측면에 필요한 자동화 수준은 프로젝트 범위에 따라 다릅니다.

보다 세부적인 수준, 특히 VBA 코드 자체에서 Access 응용 프로그램을 테스트하는 데 관심이 있다면 VB 라이트 유닛 이러한 목적을 위한 훌륭한 단위 테스트 프레임워크입니다.

내 애플리케이션에서 단위 테스트를 수행할 기회가 상대적으로 적다는 것을 알았습니다.내가 작성하는 대부분의 코드는 테이블 데이터 또는 파일링 시스템과 상호 작용하므로 기본적으로 단위 테스트가 어렵습니다.초기에는 선택적 매개변수가 있는 코드를 생성하는 조롱(스푸핑)과 유사한 접근 방식을 시도했습니다.매개변수가 사용된 경우 프로시저는 데이터베이스에서 데이터를 가져오는 대신 매개변수를 사용합니다.데이터 행과 동일한 필드 유형을 갖는 사용자 정의 유형을 설정하고 이를 함수에 전달하는 것은 매우 쉽습니다.이제 테스트하려는 절차에 테스트 데이터를 가져오는 방법이 생겼습니다.각 프로시저 내부에는 실제 데이터 소스를 테스트 데이터 소스로 교체하는 일부 코드가 있었습니다.이를 통해 내 자신의 단위 테스트 기능을 사용하여 더 다양한 기능에 대한 단위 테스트를 사용할 수 있었습니다.단위 테스트 작성은 쉽고 반복적이고 지루할 뿐입니다.결국 단위 테스트를 포기하고 다른 접근 방식을 사용하기 시작했습니다.

나는 주로 내 자신을 위해 사내 애플리케이션을 작성하므로 완벽한 코드를 갖기보다는 문제가 발견될 때까지 기다릴 여유가 있습니다.고객을 위한 애플리케이션을 작성하는 경우 일반적으로 고객은 소프트웨어 개발 비용이 얼마나 되는지 완전히 알지 못하므로 결과를 얻을 수 있는 저렴한 방법이 필요합니다.단위 테스트 작성은 프로시저에서 잘못된 데이터를 푸시하여 프로시저가 이를 적절하게 처리할 수 있는지 확인하는 테스트를 작성하는 것입니다.단위 테스트는 또한 좋은 데이터가 적절하게 처리되는지 확인합니다.현재 접근 방식은 응용 프로그램 내의 모든 프로시저에 입력 유효성 검사를 작성하고 코드가 성공적으로 완료되면 성공 플래그를 높이는 것을 기반으로 합니다.각 호출 프로시저는 결과를 사용하기 전에 성공 플래그를 확인합니다.문제가 발생하면 오류 메시지를 통해 보고됩니다.각 함수에는 성공 플래그, 반환 값, 오류 메시지, 설명 및 출처가 있습니다.사용자 정의 유형(함수 반환의 경우 fr)에는 데이터 멤버가 포함됩니다.주어진 함수는 대부분 사용자 정의 유형의 데이터 멤버 중 일부만 채웁니다.함수가 실행되면 일반적으로 성공 = true와 반환 값, 때로는 주석을 반환합니다.함수가 실패하면 성공 = false 및 오류 메시지를 반환합니다.일련의 기능이 실패하면 오류 메시지가 데이지 변경되지만 결과는 실제로 일반 스택 추적보다 훨씬 더 읽기 쉽습니다.출처도 연결되어 있으므로 문제가 발생한 위치를 알 수 있습니다.응용 프로그램은 거의 충돌하지 않으며 문제를 정확하게 보고합니다.결과는 표준 오류 처리보다 훨씬 더 좋습니다.

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을 사용하고 있는데, 이는 함수가 허용할 수 있는 제한된 알려진 선택 집합을 생성하기 때문입니다.열거형은 함수에 매개변수를 입력할 때 Intellisense도 제공합니다.나는 그들이 기능에 대한 기초적인 인터페이스를 제공한다고 가정합니다.

'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와 같은 사용자 정의 유형도 도움이 되는 코드 완성 기능을 제공합니다.프로시저 내에서는 일반적으로 결과를 반환 변수(GetOutputFolder)에 할당하기 전에 내부 결과를 익명의 내부 변수(fr)에 저장합니다.이렇게 하면 상단과 하단만 변경되므로 이름 변경 절차가 매우 쉽습니다.

요약하자면, 저는 VBA와 관련된 모든 작업을 포괄하는 ms-access를 사용하여 프레임워크를 개발했습니다.테스트는 개발 시간 단위 테스트가 아닌 절차에 영구적으로 기록됩니다.실제로 코드는 여전히 매우 빠르게 실행됩니다.1분에 만 번 호출될 수 있는 하위 함수를 최적화하는 데 매우 주의를 기울입니다.또한 코드가 개발되는 동안 프로덕션 환경에서도 사용할 수 있습니다.오류가 발생하면 사용자에게 친숙하며 일반적으로 오류의 원인과 원인이 분명합니다.오류는 애플리케이션 디자인의 중요한 원칙인 비즈니스 계층의 일부 모듈이 아닌 호출 양식에서 보고됩니다.게다가 단위 테스트 코드를 유지 관리해야 하는 부담도 없습니다. 이는 명확하게 개념화된 디자인을 코딩하는 것보다 디자인을 발전시킬 때 정말 중요합니다.

몇 가지 잠재적인 문제가 있습니다.테스트는 자동화되지 않으며 애플리케이션이 실행될 때만 새로운 불량 코드가 감지됩니다.코드는 표준 VBA 코드처럼 보이지 않습니다(보통 더 짧습니다).하지만 이 접근 방식에는 몇 가지 장점이 있습니다.사용자가 일반적으로 나에게 연락하여 의미 있는 오류 메시지를 제공하므로 오류 처리기를 사용하여 오류를 기록하는 것이 훨씬 더 좋습니다.또한 외부 데이터를 사용하는 프로시저를 처리할 수도 있습니다.JavaScript는 VBA를 생각나게 합니다. 왜 JavaScript는 프레임워크의 땅이고 ms-access의 VBA는 그렇지 않은지 궁금합니다.

이 글을 쓴 지 며칠 뒤, 한 곳을 찾았습니다. CodeProject에 관한 기사 그것은 내가 위에 쓴 것과 비슷합니다.이 기사에서는 예외 처리와 오류 처리를 비교하고 대조합니다.위에서 제안한 내용은 예외 처리와 유사합니다.

나는 이것을 시도하지 않았지만 시도해 볼 수 있습니다 SharePoint와 같은 곳에 데이터 액세스 웹 페이지로 액세스 양식을 게시합니다. 또는 웹페이지와 마찬가지로 그런 다음 다음과 같은 도구를 사용하십시오. 셀렌 일련의 테스트를 통해 브라우저를 구동합니다.

분명히 이는 단위 테스트를 통해 직접 코드를 구동하는 것만큼 이상적이지는 않지만 일부 도움이 될 수 있습니다.행운을 빌어요

액세스는 COM 응용 프로그램입니다.Windows API가 아닌 COM을 사용하십시오.Access에서 테스트합니다.

Access 응용 프로그램에 가장 적합한 테스트 환경은 Access입니다.모든 양식/보고서/테이블/코드/쿼리를 사용할 수 있고, MS Test와 유사한 스크립팅 언어가 있으며(아마도 MS Test를 기억하지 못할 수도 있습니다), 테스트 스크립트 및 테스트 결과를 보관하기 위한 데이터베이스 환경이 있습니다. 여기에서 구축한 기술을 지원서에 적용할 수 있습니다.

여기에는 좋은 제안이 있지만 아무도 중앙 집중식 오류 처리에 대해 언급하지 않은 것에 놀랐습니다.빠른 기능/하위 템플릿 작성 및 줄 번호 추가를 허용하는 추가 기능을 얻을 수 있습니다(저는 MZ 도구를 사용합니다).그런 다음 모든 오류를 기록할 수 있는 단일 함수로 보냅니다.그런 다음 단일 중단점을 설정하여 모든 오류를 중단할 수도 있습니다.

데이터 액세스 페이지는 꽤 오랫동안 MS에서 더 이상 사용되지 않았으며 처음에는 제대로 작동하지 않았습니다(설치되는 Office Widget에 의존하고 IE에서만 작동했으며 그 당시에는 형편없었습니다).

포커스를 얻을 수 있는 Access 컨트롤은 포커스가 있을 때만 창 핸들을 갖습니다. 레이블과 같이 포커스를 얻을 수 없는 액세스 컨트롤에는 창 핸들이 전혀 없습니다.이로 인해 Access는 창 핸들 기반 테스트 방식에 특히 부적합합니다.

실제로 Access에서 이런 종류의 테스트를 수행하려는 이유가 무엇인지 궁금합니다.제가 보기엔 귀하의 기본 익스트림 프로그래밍 교리처럼 들립니다. 그리고 XP의 모든 원칙과 실행 방식이 Access 응용 프로그램(사각형 말뚝, 둥근 구멍)에 적용될 수는 없습니다.

따라서 한 걸음 물러나 자신이 무엇을 달성하려고 하는지 스스로에게 물어보고 Access에서 작동하지 않는 접근 방식을 기반으로 하는 방법과 완전히 다른 방법을 활용해야 할 수도 있다는 점을 고려하십시오.

또는 그러한 종류의 자동화된 테스트가 전혀 유효하거나 Access 응용 프로그램에 유용한지 여부입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow