Question

Avec le code, les formes et les données à l'intérieur de la même base de données, je me demande quelles sont les meilleures pratiques pour la conception d'une suite de tests pour une application Microsoft Access (pour Access 2007).

L'un des principaux problèmes avec les essais de formes que seuls quelques contrôles ont un hwnd poignée et d'autres contrôles d'un seul qu'ils ont le focus, ce qui rend l'automatisation assez opaque puisque vous ne pouvez pas obtenir une liste de contrôles sur un formulaire d'agir sur.

Toute expérience à partager?

Était-ce utile?

La solution

1.Écrire Du Code Testable

Tout d'abord, arrêter d'écrire de la logique métier dans votre Formulaire de code derrière.Ce n'est pas le lieu pour cela.Il ne peut pas être correctement testé là.En fait, vous ne devriez vraiment pas avoir à tester votre forme elle-même à tous.Il devrait être une mort stupide de vue simple qui répond à une Interaction de l'Utilisateur, puis délègue la responsabilité de répondre à ces actions d'une autre classe est testable.

Comment faites-vous cela?Pour vous familiariser avec le Modèle-Vue-Contrôleur de schéma c'est un bon début.

Model View Controller diagram

Il ne peut pas être fait parfaitement en VBA, en raison du fait que l'on obtient soit des événements ou des interfaces, jamais les deux, mais vous pouvez obtenir à peu près.Considérons ce simple formulaire avec une zone de texte et un bouton.

simple form with text box and button

Dans le code du formulaire derrière, nous allons mener la zone de texte de la valeur à une propriété publique et de la relancer tous les événements qui nous intéresse.

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

Maintenant nous avons besoin d'un modèle pour travailler avec.Ici, j'ai créé un nouveau module de classe nommé MyModel.Ici se trouve le code, nous allons mettre à l'essai.Notez qu'il partage naturellement une structure similaire à celle de notre point de vue.

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

Enfin, notre contrôleur de fils ensemble.Le contrôleur est à l'écoute pour des événements de formulaire et communique les modifications au modèle et déclenche le modèle de routines.

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

Maintenant, ce code peut être exécuté à partir de n'importe quel autre module.Pour les fins de cet exemple, j'ai utilisé un module standard.Je vous encourage fortement à construire vous-même en utilisant le code que j'ai fourni et le voir fonctionner.

Private controller As FormController

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

Donc, c'est grand et tous mais qu'a-t-elle à voir avec les tests?! Ami, il a tout pour faire le test.Ce que nous avons fait, c'est rendre notre code testable.Dans l'exemple que j'ai fourni, il n'y a pas de raison que-si-jamais essayer, même pour tester l'interface graphique.La seule chose que nous avons vraiment besoin de tester la model.C'est de la vraie logique est.

Ainsi, à l'étape deux.

2.Choisir un Framework de Test Unitaire

Il n'y a pas beaucoup d'options ici.La plupart des cadres demandent d'installer les compléments COM, beaucoup de chaudière plaque, bizarre de la syntaxe, de l'écriture de tests que les commentaires, etc.C'est pourquoi je me suis impliqué dans la construction d'un moi-même, de sorte que cette partie de ma réponse n'est pas impartial, mais je vais essayer de donner un résumé fidèle de ce qui est disponible.

  1. AccUnit

    • Fonctionne uniquement dans l'Accès.
    • Vous oblige à passer des tests dans un étrange hybride de commentaires et le code.(pas d'intellisense pour le commentaire de la partie.
    • Il y est une interface graphique pour vous aider à écrire ces étranges à la recherche de tests.
    • Le projet n'a pas vu toutes les mises à jour depuis 2013.
  2. VB Lite Unité Je ne peux pas dire que j'ai personnellement utilisé.C'est là-bas, mais n'a pas vu une mise à jour depuis 2005.

  3. xlUnit xlUnit n'est pas terrible, mais c'est pas bon non plus.Il est maladroit et il y a beaucoup de chaudière plaque de code.C'est le meilleur du pire, mais il ne fonctionne pas dans l'Accès.Alors, qui est.

  4. Construire votre propre cadre

    J'ai été là et fait cela.C'est probablement plus que la plupart des gens veulent faire, mais il est tout à fait possible de construire un framework de Test Unitaire en Natif code VBA.

  5. Rubberduck VBE complément du Framework de Test Unitaire
    Avertissement:Je suis l'un des co-développeurs.

    Je suis partial, mais c'est de loin mon préféré de la bande.

    • Peu ou pas de chaudière plaque de code.
    • Intellisense est disponible.
    • Le projet est actif.
    • Plus de documentation que la plupart de ces projets.
    • Il fonctionne dans la plupart des grandes applications de bureau, et pas seulement l'Accès.
    • Il est, malheureusement, un complément COM, de sorte qu'il doit être installé sur votre machine.

3.Commencer par écrire des tests

Donc, revenons à notre code de la section 1.Le seul code que nous vraiment nécessaire pour les essais, l' MyModel.Reversed() fonction.Donc, nous allons jeter un oeil à ce que ce test pourrait ressembler.(Exemple donné utilise Rubberduck, mais c'est un test simple et pourrait se traduire dans le cadre de votre choix.)

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

Lignes directrices pour la Rédaction des Tests

  1. Le seul test qu'une seule chose à la fois.
  2. De bons tests uniquement ne fonctionne pas quand il y a un bug introduit dans le système ou les exigences ont changé.
  3. Ne pas inclure les dépendances externes tels que des bases de données et systèmes de fichiers.Ces dépendances externes peuvent faire des tests échouent pour des raisons hors de votre contrôle.Deuxièmement, ils ralentissent vos tests vers le bas.Si vos tests sont lents, vous n'aurez pas les exécuter.
  4. Test de l'utilisation de noms qui décrivent ce qu'est le test de test.Ne vous inquiétez pas si il est long.C'est le plus important qu'il est descriptif.

Je sais que la réponse était un peu long, et à la fin, mais j'espère que ça aidera certaines personnes à se lancer dans l'écriture de tests unitaires pour leur code VBA.

Autres conseils

J'ai apprécié de knox et de david réponses.Ma réponse sera quelque part entre les leurs:juste faire de l' les formes qui n'ont pas besoin d'être débogué!

Je pense que les formulaires doivent être exclusivement utilisés comme ce qu'ils sont, fondamentalement, sens de l'interface graphique seulement, signifiant ici qu'ils n'ont pas à être débogué!Le débogage de travail est alors limité à vos modules VBA et les objets, ce qui est beaucoup plus facile à manipuler.

Certes, il y a une tendance naturelle à ajouter le code VBA de formes et/ou des contrôles, spécialement lorsque l'Accès vous offre ces grands "après la mise à Jour" et "changement", les événements, mais je doute de vous conseiller pas pour mettre n'importe quel formulaire ou un contrôle spécifique de code dans le module du formulaire.Cela fait plus de maintenance et de mise à niveau très costy, où votre code est divisé entre les modules VBA et les formulaires de commandes/modules.

Cela ne signifie pas que vous ne pouvez pas utiliser plus de cela AfterUpdate l'événement!Mettez juste la norme de code dans l'événement, comme ceci:

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

Où:

  • CTLAfterUpdate est une procédure standard d'exécuter à chaque fois qu'un contrôle est mis à jour dans un formulaire

  • CTLAfterUpdateMyForm est une procédure spécifique d'exécuter à chaque fois qu'un contrôle est mis à jour sur MyForm

J'ai alors 2 modules.Le premier est

  • utilityFormEvents
    où je vais avoir mon CTLAfterUpdate générique de l'événement

La seconde est

  • MyAppFormEvents
    contenant le code spécifique de toutes les formes spécifiques de l'application MyApp et y compris le CTLAfterUpdateMyForm procédure.Bien sûr, CTLAfterUpdateMyForm pourrait pas exister si il n'y a pas de code spécifique à exécuter.C'est pourquoi nous nous tournons l' "On error" pour "resume next" ...

Choix d'une telle solution générique signifie beaucoup.Cela signifie que vous êtes d'atteindre un haut niveau de code de la normalisation (sens indolore maintenance de code).Et quand vous dites que vous n'avez pas toute forme de code spécifiques, cela signifie également que la forme de modules sont complètement normalisée, et leur production peut être automatisé:juste dire les événements que vous souhaitez gérer à la forme/niveau de contrôle, et de définir votre générique/spécifique des procédures de terminologie.
Écrivez votre code d'automation, une fois pour toutes.
Il prend quelques jours de travail, mais il donne des résultats surprenants.J'ai été en utilisant cette solution pour les 2 dernières années et c'est clairement la bonne:mes formes sont entièrement et automatiquement créé à partir de zéro avec une "Forme Tableau", liée à une "Commandes de la Table".
Je peux ensuite passer mon temps à travailler sur les procédures particulières de la forme, le cas échéant.

Code de la normalisation, même avec MS Access, est un long processus.Mais il vaut vraiment la peine!

Un autre avantage de l' L'accès étant une application COM est que vous pouvez créer un .NET application pour exécuter et tester une application Access via l'Automatisation.L'avantage de ceci est que vous pouvez ensuite utiliser un plus puissant framework de tests tels que NUnit pour écrire automatisé de faire valoir des tests sur une application d'Accès.

Par conséquent, si vous êtes à l'aise dans C# ou VB.NET combiné avec quelque chose comme NUnit ensuite, vous pouvez créer plus facilement une plus grande couverture des tests pour votre application d'Accès.

Bien qu'étant une très vieille réponse:

Il est AccUnit, une Unité spécialisée-framework de Test pour Microsoft Access.

J'ai pris une page de Python doctest concept et mise en œuvre d'un DocTests procédure dans Access VBA.Ce n'est évidemment pas une véritable unité de test de la solution.Il est encore relativement jeune, et je doute donc j'ai travaillé tous les bogues, mais je pense qu'il est assez mature pour relâcher dans la nature.

Il suffit de copier le code suivant dans un module de code standard et appuyez sur la touche F5, dans le Sous de le voir en action:

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

Copier, coller, et exécute le code ci-dessus à partir d'un module Module1 rendements:

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

Quelques remarques rapides:

  • Il n'a pas de dépendances (lorsqu'il est utilisé dans Access)
  • Il rend l'utilisation de Eval qui est une fonction dans l'Accès.Demande de modèle d'objet;cela signifie que vous pourrait l'utiliser en dehors d'Accès, mais cela nécessiterait la création d'un Accès.Objet de l'Application et pleinement la qualification de l' Eval appels
  • Il y a quelques particularités associées à Eval pour être au courant de
  • Il ne peut être utilisé sur les fonctions qui retournent un résultat qui tient sur une seule ligne

Malgré ses limites, je pense toujours qu'il fournit un peu de bang pour votre buck.

Modifier:Voici une fonction simple avec "doctest règles" de la fonction doit satisfaire.

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

Je voudrais conception de l'application pour avoir autant de travail que possible dans des requêtes et dans les sous-routines vba afin que votre test peut être constitué de remplissage de bases de données d'essai, l'exécution de jeux de la production de requêtes et de vba à l'encontre de ces bases de données et puis, regardant la sortie et en la comparant à assurer que la sortie est bonne.Cette approche n'offre pas de test de l'interface graphique de toute évidence, de sorte que vous pouvez augmenter le test avec une série de scripts de test (ici, je veux dire comme un document word qui dit ouvrir le formulaire 1, et cliquez sur le contrôle 1) qui sont exécutée manuellement.

Il dépend de la portée du projet, tel que le niveau d'automatisation nécessaires pour les essais aspect.

Si vous êtes intéressés à tester votre application d'Accès à un niveau plus granulaire spécifiquement le code VBA lui-même, puis VB Lite Unité est un excellent framework de test unitaire pour ce but.

Je trouve qu'il y a relativement peu de possibilités pour les tests unitaires dans mes applications.La plupart du code que j'écris interagit avec les données de la table ou le système de dépôt est fondamentalement difficile de test de l'unité.Dès le début, j'ai essayé une approche qui peut être similaire à moqueur (spoofing) où j'ai créé un code qui a un paramètre facultatif.Si le paramètre a été utilisé, la procédure serait d'utiliser le paramètre au lieu de l'extraction de données à partir de la base de données.Il est assez facile à mettre en place un type défini par l'utilisateur qui a les mêmes types de champ comme une ligne de données et à les transmettre à une fonction.J'ai maintenant un moyen d'obtenir des données de test dans la procédure que je veux tester.À l'intérieur de chaque procédure, il y avait un peu de code qui changé la véritable source de données pour le test de la source de données.Cela m'a permis d'utiliser les tests unitaires sur un éventail plus large de fonction, en utilisant ma propre unité de fonctions de test.L'écriture de l'unité de test est facile, c'est juste répétitif et ennuyeux.En fin de compte, j'ai donné avec les tests unitaires et a commencé à utiliser une approche différente.

J'écris des applications maison pour moi surtout si je peux me permettre d'attendre jusqu'à problèmes de me trouver plutôt que d'avoir à en avoir parfaite de code.Si je dois écrire des applications pour les clients, en général, le client n'est pas pleinement conscient de combien les frais de développement de logiciels, donc j'ai besoin d'un peu de frais de l'obtention des résultats.Écrire des tests unitaires est tout au sujet de la rédaction d'un essai qui pousse de mauvaises données à une procédure pour voir si la procédure peut gérer de manière appropriée.Les tests unitaires confirment également que les bonnes données sont traitées de manière appropriée.Mon approche est basée sur l'écriture de l'entrée de validation dans chaque procédure, au sein d'une application et l'éducation d'un indicateur de réussite lorsque le code est terminé avec succès.Chaque appel de procédure vérifie l'indicateur de réussite avant d'utiliser le résultat.Si un problème survient, il est signalé par un message d'erreur.Chaque fonction dispose d'un indicateur de réussite, une valeur de retour, un message d'erreur, un commentaire et une origine.Un type défini par l'utilisateur (fr pour le retour de la fonction) contient les données des membres.Une fonction donnée beaucoup de renseigner certaines données membres dans le type défini par l'utilisateur.Lorsqu'une fonction est exécutée, il renvoie généralement des succès = true et une valeur de retour et parfois un commentaire.Si la fonction échoue, elle renvoie succès = false et un message d'erreur.Si une chaîne de fonctions échoue, les messages d'erreur sont daisy changé, mais le résultat est en réalité beaucoup plus lisible que la trace de la pile.Les origines sont également enchaînés donc je sais pas où le problème s'est produite.L'application rarement se bloque et avec précision les rapports de tous les problèmes.Le résultat est un enfer de beaucoup mieux que le traitement standard des erreurs.

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

Code expliqué.eOutputFolder est un définis par l'utilisateur Enum comme ci-dessous

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

Je suis en utilisant le protocole Enum pour le passage de paramètres à des fonctions comme ceci crée un ensemble limité d'connus choix qu'une fonction peut accepter.Les Enums également fournir intellisense lors de la saisie des paramètres dans les fonctions.Je suppose qu'ils fournissent une interface rudimentaire pour une fonction.

'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

Un type défini par l'utilisateur comme un FunctRet fournit également la complétion de code qui permet de.Au sein de la procédure, j'ai l'habitude de stocker interne des résultats à un anonyme variable interne (fr) avant d'affecter les résultats de la variable de retour (GetOutputFolder).Cela rend le renommage des procédures très facile car seulement le haut et le bas ont changé.

Donc en résumé, j'ai développé un cadre avec ms-access, qui couvre toutes les opérations qui impliquent VBA.Le test est écrit de manière permanente dans les procédures, plutôt que d'un temps de développement, de test de l'unité.Dans la pratique, le code s'exécute toujours très rapide.Je suis très attentif à optimiser le niveau inférieur des fonctions qui peuvent être appelées à dix mille fois par minute.De plus, je peux utiliser le code dans la production comme il est en cours d'élaboration.Si une erreur se produit, il est convivial et la source et la raison de l'erreur sont généralement évident.Les erreurs sont signalées à partir de l'appel de la forme, non d'une quelconque module de la couche de gestion, qui est une entité importante de la conception de l'application.En outre, je n'ai pas le fardeau du maintien de l'unité de test de code, ce qui est vraiment important, lorsque je fais évoluer une conception plutôt que de coder un clairement conceptualisé conception.

Il existe des problèmes potentiels.Le test n'est pas automatisé et de nouveaux mauvais code est détecté uniquement lorsque l'application est exécutée.Le code ne ressemble pas à la norme du code VBA (il est généralement plus courte).Encore, l'approche présente certains avantages.Il est de loin préférable que l'utilisation d'un gestionnaire d'erreur, juste pour se connecter à une erreur que les utilisateurs généralement pas à me contacter et me donner un message d'erreur significatif.Il peut également gérer les procédures de travailler avec des données externes.JavaScript me rappelle de VBA, je me demande pourquoi JavaScript est le pays de cadres et de VBA dans ms-access ne l'est pas.

Quelques jours après avoir écrit ce post, j'ai trouvé un article sur CodeProject qui se rapproche de ce que j'ai écrit ci-dessus.L'article compare la gestion des exceptions et la gestion des erreurs.Ce que j'ai suggéré ci-dessus s'apparente à la gestion des exceptions.

Je n'ai pas essayé cela, mais vous pouvez tenter de publier vos formulaires access que l'accès aux données des pages web à quelque chose comme sharepoint ou tout comme les pages web et puis utiliser un outil tel que le sélénium pour conduire le navigateur avec une suite de tests.

Évidemment, ce n'est pas aussi idéal que la conduite directement le code par les tests unitaires, mais il peut vous obtenir une partie du chemin.bonne chance

L'accès est une application COM.Utiliser COM, pas d'API de Windows.de tester des choses dans l'Accès.

Le meilleur environnement de Test pour une Application Access est l'Accès.Tous vos Formulaires/Rapports/Tableaux/Code/Requêtes sont disponibles, il est un langage de script similaire à MS Test (Ok, vous ne vous souvenez probablement pas de MS Test), il est l'environnement de base de données pour la tenue de vos scripts de test et les résultats, et les compétences que vous construire ici sont transférables à votre demande.

Il y a de bonnes suggestions ici, mais je suis surpris que personne n'a indiqué centralisé de traitement d'erreur.Vous pouvez obtenir des compléments qui permettent rapide de la fonction/sous des gabarits et des pour ajouter des numéros de ligne (j'utilise MZ-tools).Puis de l'envoyer à toutes les erreurs d'une fonction unique où vous pouvez vous connecter à eux.Vous pouvez aussi puis arrêt sur toutes les erreurs par la fixation d'un seul point de rupture.

Pages d'Accès aux données ont été remplacés par MS pour assez un certain temps, et n'a jamais vraiment travaillé en premier lieu (ils étaient dépendants de l'Office des Widgets à installer, et ne fonctionnait que dans IE, et seulement mal à l'époque).

Il est vrai que les contrôles d'Accès qui peut se concentrer uniquement un handle de fenêtre quand ils ont le focus (et ceux qui ne peuvent pas obtenir le foyer, tels que des étiquettes, jamais un handle de fenêtre du tout).Cela rend l'Accès singulièrement inapproprié à la poignée de la fenêtre tests basés sur des régimes.

En effet, je me demande pourquoi vous voulez faire ce genre de tests dans l'Accès.Il me semble que de base de la Programmation Extrême dogme, et non pas tous les principes et les pratiques de XP peut être adapté pour fonctionner avec des applications d'Accès-square peg, trou rond.

Alors, prenez du recul et demandez-vous ce que vous essayez d'accomplir et de considérer que vous pourriez avoir besoin d'utiliser des méthodes complètement différentes de celles qui sont basées sur les approches qui ne peuvent tout simplement pas travailler à l'Accès.

Ou si ce genre de tests automatisés est valable à tous, ou même utile avec une application Access.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top