3

FastMMの誤検知で問題が発生しました。今回のリークは、フォームのテストの場合です。これは、ここで説明したものと非常によく似ています。

フォームとその中にいくつかの単純な古いVCLコントロールを取得しました。最初のテスト実行では、実際には存在しないリークが示されています。2回目の実行ではリークは発生しません。すべてのDUnitソースコードを検索しましたが、修正する理由が見つかりませんでした。誰かが私を助けることができますか？

次の理由により、テストを2回実行する余裕はありません。1。継続的インテグレーションで実行されます。2.一部のテストには実際に時間がかかり、2倍にするのは賢明ではありません。

DUnitGUIで最後の3つのオプションを確認しました。-シャットダウン時にメモリリークタイプを報告する-メモリリークが発生した場合はTestCaseに失敗する-SetUp/TearDownでメモリリークを無視する

サンプルコードは次のとおりです。

    // form
    type

    TForm2 = class(TForm)
      button1: TButton;
    end;

    implementation

    {$R *.dfm}

    // test
    type

    TTest = class(TGUITestCase)
    private
      a: TForm2;
    public
      procedure SetUp; override;
      procedure TearDown; override;
    published
      procedure Test;
    end;

    implementation

    procedure TTest.Setup;
    begin
      a := TForm2.Create(nil);
    end;

    procedure TTest.TearDown;
    begin
      FreeAndNil(a);
    end;

    procedure TTest.Test;
    begin
      a.Show;
      a.close;
    end;
4

2 に答える 2

4

フォームを2回解放しています。アクションをcaFreeに設定すると、フォーム自体が自動的に解放されます。したがって、OnCloseメソッドを削除するか、テスト自体でフォームを作成し、フォームを解放せずにsetupメソッドとteardownメソッドを削除することをお勧めします。CaFreeがそれを処理します。

于 2012-09-03T23:15:56.740 に答える
0

ダウンロードされたバージョンでは、状況が時折発生しました。ばかげているように思われますが、根本的な原因は次のとおりです。DUnitGUIのロード後に「F9」を押すのが速すぎると、問題が発生します。数秒待っても、リークは報告されません。

ここでは、FormShowイベントをオーバーライドしてテストを自動的に開始するため、私の場合は常に問題が発生していました。したがって、実行を2秒遅らせることで、私の問題は解決しました。

私を助けてくれてありがとう@balazs。

于 2012-11-27T17:12:47.980 に答える