Doceniam odpowiedzi Knoxa i Davida. Moja odpowiedź będzie gdzieś między nimi: wystarczy zrobić formularze, które nie wymagają debugowania!

Myślę, że formularze powinny być używane wyłącznie jako to, czym są w zasadzie, czyli interfejs graficzny tylko, oznacza to, że nie muszą być debugowane! Zadanie debugowania jest następnie ograniczone do modułów i obiektów VBA, co jest o wiele łatwiejsze w obsłudze.

Istnieje oczywiście naturalna tendencja do dodawania kodu VBA do formularzy i / lub kontrolek, szczególnie gdy Access oferuje Ci te świetne zdarzenia "po aktualizacji" i "przy zmianie" , ale zdecydowanie radzę ci nie umieszczać żadnego formularza lub kodu kontrolnego w module formularza. To sprawia, że dalsza Konserwacja i aktualizacja są bardzo kosztowne, gdzie kod jest podzielony między Moduły VBA i formularze / moduły sterowania.

To nie znaczy, że nie możesz już używać tego AfterUpdate eventu! Wystarczy umieścić standardowy kod w zdarzeniu, jak to:

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

Gdzie:

• CTLAfterUpdate jest to standardowa procedura uruchamiana za każdym razem, gdy kontrolka jest aktualizowana w formie

• CTLAfterUpdateMyForm jest to specyficzna procedura uruchamiana za każdym razem, gdy kontrola jest aktualizowana na MyForm

Mam wtedy 2 moduły. Pierwszy to

• utilityFormEvents
  gdzie będę miał moje ctlafterupdate generic event

Drugi to

• MyAppFormEvents
  zawierający specyficzny kod wszystkich specyficznych formularze aplikacji MyApp w tym procedura CTLAfterUpdateMyForm. Oczywiście, CTLAfterUpdateMyForm może nie istnieć, jeśli nie ma określonego kodu do uruchomienia. To dlatego odwracamy "W przypadku błędu" do "Wznów następny"...

Wybór takiego ogólnego rozwiązania wiele znaczy. Oznacza to, że osiągasz wysoki poziom normalizacji kodu (czyli bezbolesnej konserwacji kodu). A kiedy mówisz, że nie masz żadnego kodu specyficznego dla formularza, oznacza to również, że moduły formularza są w pełni standaryzowane, a ich produkcja może być automatyczne: po prostu powiedz, którymi zdarzeniami chcesz zarządzać na poziomie formularza/kontroli i zdefiniuj swoją ogólną / określoną terminologię procedur.
Napisz swój kod automatyzacji, raz na zawsze.
Zajmuje to kilka dni pracy, ale daje ekscytujące rezultaty. Korzystam z tego rozwiązania od 2 lat i jest ono oczywiście właściwe: moje formularze są w pełni i automatycznie tworzone od podstaw za pomocą "tabeli formularzy", połączonej z "Tabela Kontrolna".
Następnie mogę poświęcić swój czas na pracę nad konkretnymi procedurami formularza, jeśli w ogóle istnieją.

Normalizacja kodu, nawet z MS Access, jest długim procesem. Ale to naprawdę jest warte bólu!

Kolejną zaletą dostępu będącego aplikacją COM jest to, że można utworzyć aplikację . NET do uruchamiania i testowania aplikacji Access za pomocą automatyzacji. Zaletą tego jest to, że możesz użyć bardziej wydajnego frameworka testowego, takiego jak NUnit do pisania automatycznych testów assert przeciwko aplikacji Access.

Dlatego jeśli jesteś biegły w C # lub VB.NET w połączeniu z czymś takim jak NUnit można łatwiej stworzyć większy zasięg testu dla Twoja aplikacja dostępu.

Chociaż to bardzo stara odpowiedź:

Istnieje AccUnit , specjalistyczny Framework testowy dla Microsoft Access.

Wziąłem stronę zkoncepcji Pythona doctest i zaimplementowałem procedurę Doctestów w Access VBA. To oczywiście nie jest pełne rozwiązanie do testowania jednostek. Jest jeszcze stosunkowo młody, więc wątpię, że wypracowałem wszystkie błędy, ale myślę, że jest wystarczająco dojrzały, aby wypuścić go na wolność.

Po prostu skopiuj poniższy kod do standardowego modułu kodu i naciśnij F5 wewnątrz Sub, aby zobaczyć go w akcji:

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

Kopiowanie, wklejanie i uruchamianie powyższego kodu z wydajność modułu o nazwie Module1:

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

Kilka szybkich notek:

Nie ma żadnych zależności (gdy jest używany z poziomu dostępu)
• używa Eval, która jest funkcją w dostępie.Application object model; oznacza to, że możesz używać go poza Access, ale wymagałoby to utworzenia dostępu.Obiekt aplikacji i w pełni kwalifikujący wywołania Eval
• są pewne idiosynkrazje związane z Eval być świadomym
• może może być używany tylko w funkcjach, które zwracają wynik, który pasuje do pojedynczej linii

Pomimo swoich ograniczeń, nadal uważam, że zapewnia sporo huku za Twoją kasę.

Edit : oto prosta funkcja z "doctest rules" funkcja musi spełniać.

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

Chciałbym zaprojektować aplikację tak, aby miała jak najwięcej pracy w zapytaniach i podprogramach vba, tak aby twoje testy mogły składać się z wypełniania testowych baz danych, uruchamiania zestawów zapytań produkcyjnych i vba przeciwko tym bazom danych, a następnie patrząc na wyjście i porównując, aby upewnić się, że wyjście jest dobre. To podejście oczywiście nie testuje GUI, więc można rozszerzyć testowanie o serię skryptów testowych (tutaj mam na myśli jak dokument word, który mówi otwarty formularz 1, i kliknij control 1), które są wykonywane ręcznie.

To zależy od zakresu projektu jako poziomu automatyzacji niezbędnego dla aspektu testowego.

Jeśli jesteś zainteresowany testowaniem aplikacji Access na bardziej szczegółowym poziomie, a konkretnie samego kodu VBA, VB Lite Unit jest świetnym frameworkiem do testowania jednostek w tym celu.

Są tu dobre sugestie, ale dziwię się, że nikt nie wspomniał o scentralizowanym przetwarzaniu błędów. Można uzyskać dodatki, które pozwalają na szybkie function / sub template i do dodawania numerów linii (używam MZ-tools). Następnie wyślij wszystkie błędy do jednej funkcji, gdzie możesz je zarejestrować. Możesz również złamać wszystkie błędy, ustawiając pojedynczy punkt przerwania.

Uważam, że możliwości testowania jednostkowego w moich aplikacjach jest stosunkowo niewiele. Większość kodu, który piszę, współdziała z danymi tabeli lub systemem plików, więc zasadniczo trudno jest przetestować jednostki. Na początku próbowałem podejścia, które może być podobne do wyśmiewania (spoofing), gdzie stworzyłem kod, który miał opcjonalny parametr. Jeżeli parametr został użyty, wtedy procedura użyje parametru zamiast pobierać dane z bazy danych. Bardzo łatwo jest skonfigurować zdefiniowaną przez użytkownika typ, który ma te same typy pól co wiersz danych i przekazuje je do funkcji. Mam teraz sposób na wprowadzenie danych testowych do procedury, którą chcę przetestować. Wewnątrz każdej procedury znajdował się jakiś kod, który zamieniał prawdziwe źródło danych na źródło danych testowych. To pozwoliło mi używać testów jednostkowych na szerszej gamie funkcji, używając własnych funkcji testowania jednostkowego. Pisanie testu jednostkowego jest łatwe, jest po prostu powtarzalne i nudne. W końcu zrezygnowałem z testów jednostkowych i zacząłem używać inne podejście.

Piszę aplikacje wewnętrzne głównie dla siebie, więc mogę sobie pozwolić czekać, aż problemy mnie znajdą, zamiast mieć doskonały kod. Jeśli piszę aplikacje dla klientów, zazwyczaj klient nie jest w pełni świadomy, ile kosztuje tworzenie oprogramowania, więc potrzebuję taniego sposobu na uzyskanie wyników. Pisanie testów jednostkowych polega na pisaniu testu, który wypycha złe dane w procedurze, aby sprawdzić, czy procedura poradzi sobie z tym odpowiednio. Testy jednostkowe potwierdzają również, że dobre dane są odpowiednio obsługiwane. Moje obecne podejście opiera się na zapisywaniu walidacji danych wejściowych do każdej procedury w aplikacji i podnoszeniu flagi sukcesu po pomyślnym zakończeniu kodu. Każda procedura wywołująca sprawdza flagę success przed użyciem wyniku. Jeśli wystąpi problem, jest on zgłaszany za pomocą komunikatu o błędzie. Każda funkcja ma flagę sukcesu, wartość zwrotną, komunikat o błędzie, komentarz i pochodzenie. Typ zdefiniowany przez użytkownika (FR dla zwracania funkcji) zawiera członków danych. Każda dana funkcja wiele wypełnia tylko niektóre z członków danych w typie zdefiniowanym przez użytkownika. Gdy funkcja jest uruchomiona, zwykle zwraca success = true i wartość zwracaną, a czasami komentarz. Jeśli funkcja nie powiedzie się, zwraca success = false i Komunikat o błędzie. Jeśli łańcuch funkcji zawiedzie, komunikaty o błędach są zmieniane, ale wynik jest o wiele bardziej czytelny niż zwykły ślad stosu. Źródła są również przykute, więc wiem, gdzie wystąpił problem. Na aplikacja rzadko ulega awarii i dokładnie zgłasza wszelkie problemy. Wynik jest o wiele lepszy niż standardowa obsługa błędów.

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

Kod wyjaśniony. eOutputFolder jest zdefiniowanym przez użytkownika Enum jak poniżej

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

Używam Enum do przekazywania parametrów do funkcji, ponieważ tworzy to ograniczony zestaw znanych wyborów, które może zaakceptować funkcja. Enums dostarcza również intellisense przy wprowadzaniu parametrów do funkcji. Przypuszczam, że zapewniają one podstawowy interfejs dla funkcja.

'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

Typ zdefiniowany przez użytkownika, taki jak FunctRet, również zapewnia uzupełnianie kodu, co pomaga. W ramach procedury zwykle przechowuję wewnętrzne wyniki do anonimowej zmiennej wewnętrznej (fr) przed przypisaniem wyników do zmiennej zwrotnej (GetOutputFolder). To sprawia, że procedury zmiany nazwy są bardzo łatwe, ponieważ tylko góra i dół zostały zmienione.

Są pewne potencjalne problemy. Testowanie nie jest zautomatyzowane, a nowy zły kod jest wykrywany tylko podczas uruchamiania aplikacji. Kod nie wygląda jak standardowy kod VBA (zwykle jest krótszy). Podejście to ma jednak pewne zalety. Jest o wiele lepiej że za pomocą obsługi błędów tylko do logowania błędu, ponieważ użytkownicy zwykle kontaktują się ze mną i dać mi znaczący komunikat o błędzie. Może również obsługiwać procedury, które działają z danymi zewnętrznymi. JavaScript przypomina mi VBA, ciekawe dlaczego JavaScript to kraina frameworków, a VBA w ms-access nie.

Kilka dni po napisaniu tego postu, znalazłem artykuł na CodeProject , który jest zbliżony do tego, co napisałem powyżej. Artykuł porównuje i kontrastuje obsługę wyjątków i obsługi błędów. To, co zasugerowałem powyżej, jest podobne do obsługi wyjątków.

Nie próbowałem tego, ale możesz spróbować opublikować swoje formularze dostępu jako strony internetowe dostępu do danych do czegoś takiego jak sharepoint lub tak jak strony internetowe , a następnie użyć narzędzia, takiego jak selenium , aby uruchomić przeglądarkę z zestawem testów.

Oczywiście nie jest to tak idealne, jak kierowanie kodem bezpośrednio przez testy jednostkowe, ale może Ci to pomóc. powodzenia

Access jest aplikacją COM. Użyj COM, NIE Windows API. aby przetestować rzeczy w Access.

Najlepszym środowiskiem testowym dla aplikacji Access jest Access. Wszystkie Twoje formularze/raporty/tabele/Kod / zapytania są dostępne, istnieje język skryptowy podobny do MS Test( Ok, prawdopodobnie nie pamiętasz MS Test), Istnieje środowisko bazy danych do przechowywania skryptów testowych i wyników testów, a umiejętności, które tutaj zbudujesz, można przenieść do Twojej aplikacji.

Strony dostępu do danych były przestarzałe przez MS od dłuższego czasu i nigdy tak naprawdę nie działały (były zależne od zainstalowanych widżetów Office i działały tylko w IE, i tylko wtedy źle).

Prawdą jest, że kontrolki dostępu, które mogą uzyskać fokus, mają uchwyt okna tylko wtedy, gdy mają fokus (a te, które nie mogą uzyskać Fokusa, takie jak etykiety, nigdy nie mają uchwytu okna). To sprawia, że dostęp jest wyjątkowo nieodpowiedni do testów opartych na klamkach okiennych / align = "left" /

Rzeczywiście, mam pytanie, dlaczego chcesz robić tego rodzaju testy w Access. Brzmi to dla mnie jak twój podstawowy dogmat programowania Extreme, a nie wszystkie zasady i praktyki XP można dostosować do pracy z aplikacjami dostępowymi-kwadratowy kołek, okrągły otwór.

Więc cofnij się i zadaj sobie pytanie, co próbujesz osiągnąć i weź pod uwagę, że może być konieczne użycie zupełnie innych metod niż te, które są oparte na podejściach, które po prostu nie mogą działać w Dostęp.

Lub czy tego rodzaju zautomatyzowane testy są w ogóle ważne lub nawet przydatne w aplikacji Access.