6

これは健全性チェックです。これは、コードでこれが正しいと判断したためです。関数型コードとは異なり、ステートフルGUIのテストは、状態の設定、組み合わせのケース分析、およびネイバー/コラボレーター/リスナーのモック/偽造などのために、残念ながらかなりの重みがあります。私は何かが足りないのですか？ご意見をいただきありがとうございます。

ノート：

  • テストはJVMで実行されており、すべてがPOJOです。
  • これまでのところ、ユニットサイズを大きくすることで、いくつかの単純化を実現しました。より多くのピースを接着してテストします。

新しいメモ：

  • jUnitとMockitoを使用しています。
4

1 に答える 1

5
  1. コードの重複を避けます。共通のセットアップ コードとアクションを抽出する必要があります
  2. 階層を探します。1 つの巨大なテスト シナリオを作成しないでください。共通の行をまとめて、意味のある名前のメソッドに抽出します。多層化されたテスト シナリオの構築に進む
  3. より良いツールを検討してください。 cucumber、FEST assertions、テスト DSL としての Scala または Groovy (本番コードで使用しない場合でも)、mockito ...

それに加えて、コードの本番行数とテスト行数の関係は関係ありません。数十回のテストを必要とする非常に多くのエッジケースを持つ非常に短いコードの例を簡単に見つけることができます。

そしてSQLiteの実際の例（強調鉱山）：

[...] ライブラリは、約 81.3 KSLOC の C コードで構成されています。[...] 比較すると、プロジェクトには1124 倍のテスト コードとテスト スクリプト(91421.1 KSLOC) があります。

そうです、本番コードの各行あたり約 1100 行のテスト コードです。

于 2012-11-03T20:22:39.280 に答える