同じデータベース内のコード、フォーム、およびデータを使用して、Microsoft Access アプリケーション (Access 2007 など) の一連のテストを設計するためのベスト プラクティスは何か疑問に思っています。
フォームのテストに関する主な問題の 1 つは、少数のコントロールhwndのみがハンドルを持ち、他のコントロールはフォーカスのある 1 つしか取得できないことです。これにより、フォーム上のコントロールのリストを取得して操作することができないため、自動化が非常に不透明になります。
共有する経験はありますか？
まず、ビジネス ロジックをフォームのコード ビハインドに記述するのをやめます。それはその場所ではありません。そこでは適切にテストできません。実際、フォーム自体をテストする必要はまったくありません。これは、ユーザー インタラクションに応答し、それらのアクションに応答する責任をテスト可能な別のクラスに委任する、非常に単純なビューである必要があります。
どうやってそれをしますか？Model-View-Controller パターンに慣れることは、良い出発点です。
イベントまたはインターフェイスのいずれかを取得し、両方を取得することはないため、VBA で完全に実行することはできませんが、かなり近づけることはできます。テキスト ボックスとボタンを持つ次の単純なフォームを考えてみましょう。
フォームのコード ビハインドでは、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 に進みます。
ここには多くのオプションはありません。ほとんどのフレームワークでは、COM アドイン、多数のボイラー プレート、奇妙な構文、コメントとしてのテストの記述などをインストールする必要があります。利用可能なものの公正な要約を提供します。
VB Lite Unit 個人的に使ったとは言えません。公開されていますが、2005 年以降更新されていません。
xlUnit xlUnit は悪くはありませんが、良くもありません。それは不格好で、定型コードがたくさんあります。これは最悪の最善ですが、Access では機能しません。それで、それは出ました。
独自のフレームワークを構築する
私はそこにいて、それをしました。おそらくほとんどの人が入りたいと思っている以上のものですが、ネイティブ VBA コードで単体テスト フレームワークを構築することは完全に可能です。
Rubberduck VBE アドインのユニット テスト フレームワーク
免責事項: 私は共同開発者の 1 人です。
私は偏見がありますが、これは群を抜いて私のお気に入りです。
それでは、セクション 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
回答が少し長く、遅くなったことは承知していますが、一部の人々が 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コントロールがフォームで更新されるたびに実行される標準的な手順です。
CTLAfterUpdateMyFormMyForm でコントロールが更新されるたびに実行される特定のプロシージャです。
私は2つのモジュールを持っています。最初のものは
utilityFormEvents二つ目は
MyAppFormEventsこのような一般的なソリューションを選択することには大きな意味があります。これは、高レベルのコード正規化に到達していることを意味します (コードの簡単なメンテナンスを意味します)。また、フォーム固有のコードがないということは、フォーム モジュールが完全に標準化されており、その生成を自動化できることも意味します。フォーム/コントロール レベルで管理したいイベントを指定し、一般的/特定の手順の用語。
自動化コードを一度だけ書いてください。
作業には数日かかりますが、エキサイティングな結果が得られます。私は過去 2 年間このソリューションを使用してきましたが、明らかに正しいソリューションです。私のフォームは、「コントロール テーブル」にリンクされた「フォーム テーブル」を使用してゼロから完全かつ自動的に作成されます。
その後、フォームの特定の手順があれば、その作業に時間を費やすことができます。
MS Access を使用した場合でも、コードの正規化は長いプロセスです。しかし、それは本当に苦労する価値があります！
AccessがCOMアプリケーションであることのもう1つの利点は、Automationを介してAccessアプリケーションを実行およびテストするための.NETアプリケーションを作成できることです。これの利点は、NUnitなどのより強力なテストフレームワークを使用して、Accessアプリに対する自動アサートテストを作成できることです。
したがって、NUnitなどと組み合わせたC＃またはVB.NETのいずれかに習熟している場合は、Accessアプリのテストカバレッジをより簡単に作成できます。
Python の doctest の概念から 1 ページ取り出して、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
いくつかの簡単なメモ:
EvalAccess.Application オブジェクト モデルの関数である whichを利用します。これは、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
それは非常に古い答えですが：
Microsoft Access に特化した単体テスト フレームワークであるAccUnitがあります。
クエリと vba サブルーチンで可能な限り多くの作業が行われるようにアプリケーションを設計して、テスト データベースにデータを入力し、それらのデータベースに対して実稼働クエリと vba のセットを実行し、出力を確認してテストを構成できるようにします。比較して、出力が良好であることを確認します。このアプローチは明らかに GUI をテストしないので、手動で実行される一連のテスト スクリプト (ここでは、フォーム 1 を開いてコントロール 1 をクリックするという単語文書のようなものです) を使用してテストを強化できます。
テストの側面に必要な自動化のレベルとして、プロジェクトの範囲によって異なります。
Access アプリケーションをより詳細なレベル、特に VBA コード自体でテストすることに関心がある場合、VB Lite Unitはその目的に適した優れた単体テスト フレームワークです。
アプリケーションで単体テストを行う機会は比較的少ないことがわかりました。私が書いたコードのほとんどは、テーブル データまたはファイリング システムと対話するため、単体テストは基本的に困難です。早い段階で、オプションのパラメーターを持つコードを作成するモック (スプーフィング) に似たアプローチを試みました。パラメータが使用された場合、プロシージャはデータベースからデータをフェッチする代わりにパラメータを使用します。データ行と同じフィールド タイプを持つユーザー定義タイプを設定し、それを関数に渡すのは非常に簡単です。これで、テストしたいプロシージャーにテスト・データを取り込む方法ができました。各プロシージャ内には、実際のデータ ソースをテスト データ ソースに置き換えるコードが含まれていました。これにより、さまざまな機能で単体テストを使用できるようになりました。私自身の単体テスト機能を使用しています。単体テストを書くのは簡単ですが、反復的で退屈です。結局、私は単体テストをあきらめ、別のアプローチを使い始めました。
私は主に自分自身のために社内アプリケーションを書いているので、完璧なコードを用意するのではなく、問題が見つかるまで待つことができます。私が顧客のためにアプリケーションを作成する場合、通常、顧客はソフトウェア開発コストを十分に認識していないため、結果を得るには低コストの方法が必要です。単体テストを作成するということは、プロシージャーで不良データをプッシュして、プロシージャーが適切に処理できるかどうかを確認するテストを作成することです。単体テストでは、適切なデータが適切に処理されることも確認されます。私の現在のアプローチは、アプリケーション内のすべてのプロシージャに入力検証を記述し、コードが正常に完了したときに成功フラグを立てることに基づいています。各呼び出しプロシージャは、結果を使用する前に成功フラグをチェックします。問題が発生した場合は、エラー メッセージで報告されます。各関数には成功フラグがあり、戻り値、エラー メッセージ、コメント、原点。ユーザー定義型 (関数の戻り値を表す fr) には、データ メンバーが含まれます。特定の関数は、多くの場合、ユーザー定義型のデータ メンバーの一部のみを設定します。関数が実行されると、通常は success = true と戻り値が返され、場合によってはコメントが返されます。関数が失敗すると、success = false とエラー メッセージが返されます。関数のチェーンが失敗した場合、エラー メッセージはデイジー チェンジされますが、結果は実際には通常のスタック トレースよりもはるかに読みやすくなります。オリジンもチェーンされているので、どこで問題が発生したかがわかります。アプリケーションがクラッシュすることはめったになく、問題があれば正確に報告します。結果は、標準のエラー処理よりもはるかに優れています。ユーザー定義型 (関数の戻り値を表す fr) には、データ メンバーが含まれます。特定の関数は、多くの場合、ユーザー定義型のデータ メンバーの一部のみを設定します。関数が実行されると、通常は success = true と戻り値が返され、場合によってはコメントが返されます。関数が失敗すると、success = false とエラー メッセージが返されます。関数のチェーンが失敗した場合、エラー メッセージはデイジー チェンジされますが、結果は実際には通常のスタック トレースよりもはるかに読みやすくなります。オリジンもチェーンされているので、どこで問題が発生したかがわかります。アプリケーションがクラッシュすることはめったになく、問題があれば正確に報告します。結果は、標準のエラー処理よりもはるかに優れています。ユーザー定義型 (関数の戻り値を表す fr) には、データ メンバーが含まれます。特定の関数は、多くの場合、ユーザー定義型のデータ メンバーの一部のみを設定します。関数が実行されると、通常は success = true と戻り値が返され、場合によってはコメントが返されます。関数が失敗すると、success = false とエラー メッセージが返されます。関数のチェーンが失敗した場合、エラー メッセージはデイジー チェンジされますが、結果は実際には通常のスタック トレースよりもはるかに読みやすくなります。オリジンもチェーンされているので、どこで問題が発生したかがわかります。アプリケーションがクラッシュすることはめったになく、問題があれば正確に報告します。結果は、標準のエラー処理よりもはるかに優れています。通常は success = true と戻り値、場合によってはコメントを返します。関数が失敗すると、success = false とエラー メッセージが返されます。関数のチェーンが失敗した場合、エラー メッセージはデイジー チェンジされますが、結果は実際には通常のスタック トレースよりもはるかに読みやすくなります。オリジンもチェーンされているので、どこで問題が発生したかがわかります。アプリケーションがクラッシュすることはめったになく、問題があれば正確に報告します。結果は、標準のエラー処理よりもはるかに優れています。通常は success = true と戻り値、場合によってはコメントを返します。関数が失敗すると、success = 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
関数にパラメーターを渡すために列挙型を使用しています。これは、関数が受け入れることができる既知の選択肢の限られたセットを作成するためです。列挙型は、パラメーターを関数に入力する際のインテリセンスも提供します。関数の初歩的なインターフェースを提供していると思います。
'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 分間に 1 万回呼び出される可能性のある低レベルの関数を最適化するように細心の注意を払っています。さらに、開発中のコードを本番環境で使用できます。エラーが発生した場合、それはユーザーフレンドリーであり、エラーのソースと理由は通常明らかです。エラーは、アプリケーション設計の重要な原則であるビジネス層の一部のモジュールからではなく、呼び出し元のフォームから報告されます。さらに、ユニット テスト コードを維持する負担がありません。これは、明確に概念化された設計をコーディングするのではなく、設計を進化させるときに非常に重要です。
潜在的な問題がいくつかあります。テストは自動化されておらず、新しい不正コードはアプリケーションの実行時にのみ検出されます。コードは、標準の VBA コードのようには見えません (通常はより短い)。それでも、このアプローチにはいくつかの利点があります。エラーをログに記録するためだけにエラー ハンドラーを使用する方がはるかに優れています。ユーザーは通常、私に連絡して意味のあるエラー メッセージを提供してくれるからです。また、外部データを操作するプロシージャも処理できます。JavaScript は VBA を思い起こさせます。なぜ JavaScript はフレームワークの世界であり、ms-access の VBA はそうではないのでしょうか。
この記事を書いてから数日後、私が上で書いたものに近い記事を The CodeProjectで見つけました。この記事では、例外処理とエラー処理を比較対照しています。上で提案したことは、例外処理に似ています。
ここには良い提案がありますが、集中エラー処理について誰も言及していないことに驚いています。関数/サブテンプレートをすばやく作成し、行番号を追加できるアドインを入手できます (私は MZ ツールを使用しています)。次に、すべてのエラーをログに記録できる単一の関数に送信します。また、1 つのブレーク ポイントを設定することで、すべてのエラーでブレークすることもできます。
アクセスはCOMアプリケーションです。Windows APIではなく、COMを使用します。Accessで物事をテストします。
Accessアプリケーションに最適なテスト環境はAccessです。すべてのフォーム/レポート/テーブル/コード/クエリが利用可能で、MS Testに似たスクリプト言語があり（おそらくMS Testを覚えていないでしょう）、テストスクリプトとテスト結果を保持するためのデータベース環境があります。ここで構築したスキルは、アプリケーションに転送できます。
私はこれを試していませんが、アクセス フォームをデータ アクセス Web ページとして sharepoint などに公開するか、単に Web ページとして公開し、 seleniumなどのツールを使用して一連のテストでブラウザを駆動することができます。
明らかに、これは単体テストを介してコードを直接実行するほど理想的ではありませんが、方法の一部になる可能性があります。幸運を
データ アクセス ページは、かなり長い間 MS によって廃止されており、そもそも実際に機能することはありませんでした (それらは、インストールされている Office ウィジェットに依存しており、IE でのみ機能し、そのときはうまく動作しませんでした)。
確かに、フォーカスを取得できる Access コントロールは、フォーカスを取得したときにのみウィンドウ ハンドルを持ちます (ラベルなど、フォーカスを取得できない Access コントロールには、ウィンドウ ハンドルがまったくありません)。これにより、Access は、ウィンドウ ハンドル駆動型のテスト体制に対して非常に不適切になります。
確かに、なぜこの種のテストを Access で行いたいのか疑問に思います。私には、あなたの基本的なエクストリーム プログラミングの教義のように思えます。また、XP の原則と実践のすべてが、Access アプリケーションで動作するように適応できるわけではありません。
したがって、一歩下がって、何を達成しようとしているのかを自問し、Access では機能しないアプローチに基づく方法とはまったく異なる方法を使用する必要がある可能性があることを検討してください。
または、その種の自動テストが Access アプリケーションで有効かどうか、あるいは有用かどうか。