問題タブ [unit-testing]

同じデータベース内のコード、フォーム、およびデータを使用して、Microsoft Access アプリケーション (Access 2007 など) の一連のテストを設計するためのベスト プラクティスは何か疑問に思っています。

フォームのテストに関する主な問題の 1 つは、少数のコントロールhwndのみがハンドルを持ち、他のコントロールはフォーカスのある 1 つしか取得できないことです。これにより、フォーム上のコントロールのリストを取得して操作することができないため、自動化が非常に不透明になります。

共有する経験はありますか？

単体テストの名前が時間の経過とともに古くなる可能性があり、テスト自体が最も重要であると考える場合、賢明なテスト名を選択することが重要ですか？

すなわち

詩

私は単体テストを実装しようとしてきましたが、現在、次のことを行うコードがいくつかあります。

1. 外部データベースのクエリ、フィード テーブルへの読み込み
2. フィードとデータ テーブルのデルタであるビューをクエリし、フィード テーブルと一致するようにデータ テーブルを更新する

私の単体テスト戦略は次のとおりです。

自由に操作できるテスト データベースがあります。

1. setUP() で、いくつかのデータをテスト用データベースにロードします
2. テストデータベースをソースとして使用して、コードを実行します
3. データテーブルを調べて、カウントと特定のレコードの存在/非存在をチェックします
4. テストデータベースをクリアし、別のデータセットをロードします
5. コードを再度実行する
6. データテーブルを再度調べる

明らかに、特定のレコードを追加、削除、更新する必要があることがわかるように、ソースデータベースにロードするデータセットを設定しています。

これは少し面倒なようですが、もっと簡単な方法があるはずですか? 助言がありますか？

私は、「テスト感染」した人々について読み続けています。つまり、TDD を「取得」するだけでなく、TDD なしでは生きていけないということです。彼らはいわば「変身」したのだ。問題は、どうすればそのようになるかです。

少し前に、 MartinFowlerによるMocksAre n't Stubsの記事を読みましたが、複雑さの追加に関して外部の依存関係が少し怖いことを認めなければならないので、質問したいと思います。

単体テストで使用するのに最適な方法は何ですか？

テスト対象のメソッドの依存関係を自動的にモックするために、常にモックフレームワークを使用する方がよいでしょうか、それとも、たとえばテストスタブなどのより単純なメカニズムを使用する方がよいでしょうか。

MbUnitを何度もインストールする必要がありましたが、MbUnitと呼ばれるものが引き続き付属しています。

Gallilo Icarus GUI Test Runner

MbUnit GUIの単なるアップデートだと思って使用してみましたが、MbUnitテストが検出されず、アセンブリが正しく開かないこともあります。

おそらく私はそれを見落としているだけですが、新しいテストプラットフォームと関係があることを除いて、彼らのWebサイトでも多くの答えを見つけることができませんでした。

誰かが私にこれが何であるかについてのより良い説明を与えることができますか？

UIのテストにWatiNを使用していますが、1ページ（残念ながらチームの管理下にはありません）の読み込みが完了するまでに永遠に時間がかかります。ページが完全にレンダリングを完了する前に、WatiNにページ上のリンクをクリックさせる方法はありますか？

ToStringXML を生成するメソッドを持つクラスがあります。有効なxmlを生成していることを確認するために単体テストを行いたいです。XML を検証するための DTD があります。

DTD への依存を避けるために、DTD を単体テスト内の文字列として含める必要がありますか、またはこれを行うためのよりスマートな方法はありますか?

Core アセンブリが特定のクラスを公開しないようにしたいのですが、それでもテストできるようにしたいと考えています。どうやってやるの ？

単体テストにフィードできる BNF 文法からテスト文字列を生成するツールを使用した経験のある人はいますか?