7

Python / PyQt で書かれた非常にデータ中心のアプリケーションがあります。主にまだ実際のテストが実施されておらず、明らかに変更する必要があるため、UI をコアから実際に分離するためにリファクタリングを行う予定です。

すでにある程度の分離があり、かなりの数のことを正しい方法で行ったと思いますが、完璧にはほど遠いです. どのようなことが私を悩ませているかを示すために、2 つの例を示します。

  • ユーザーがデータ オブジェクトの表現を右クリックすると、ポップアップするコンテキスト メニューがデータ オブジェクトによって作成されますが、このデータ オブジェクト (基本的にデータベース行の ORM 表現) は明らかに UI とは関係ありません。 .

  • データベースに何かが書き込まれ、書き込みが失敗した場合 (たとえば、データベース レコードが別のユーザーによってロックされているため)、従来の「再試行/中止」メッセージ ボックスがユーザーに表示されます。このダイアログは、データ プロバイダー* によって作成されますが、プロバイダーには UI 機能がないことは明らかです。明らかに、プロバイダーは代わりに例外を発生させたり、失敗を示したりすることができ、UI はそれをキャッチしてそれに応じて動作することができます。

    * これは、基本的にデータベース テーブルを表し、そのデータ オブジェクトとデータベース エンジンの間を仲介するオブジェクトに対して使用する言葉です。それが通常「プロバイダー」と呼ばれるものかどうかはわかりません

私はテストの経験がないので、テスト可能性の問題などを簡単に「感じる」ことはありませんが、それに入る前に、いくつかの再編成を行う必要があります。

関連する複雑なビジネス ロジックはありません (主に CRU D だけです。はい、D がなくても) 。

私の計画は、Qt インターフェースの代わりに Web フロントエンドまたはテキストベースのインターフェースに置き換えるために、UI 部分を簡単に切り取ることができるという考えを念頭に置いてリファクタリングを開始することです。一方、Qt 自体は依然としてコアによって使用されます。これは、シグナル/スロット メカニズムがかなりの数の場所で使用されているためchangedです。

それで、私の質問: それはテスト容易性と保守性を向上させるための実行可能なアプローチですか? 特にPythonを念頭に置いて、他に何かコメントはありますか?

4

4 に答える 4

7

まだ読んでいない場合は、Michael Feathers による "Working Effectsly with Legacy Code" を読んでください。まさにこの種の状況を扱っており、それに対処するための豊富なテクニックを提供しています。

彼の重要なポイントの 1 つは、リファクタリングの前にいくつかのテストを実施することです。単体テストには適していないため、エンドツーエンドのテストを実施してみてください。Qt には、GUI を駆動するための独自のテスト フレームワークがあると思います。そのため、既知のデータベースに対して GUI を操作するテストを追加し、結果を検証します。コードをクリーンアップするときに、エンド ツー エンド テストを単体テストに置き換えたり、拡張したりできます。

于 2010-01-17T16:58:56.207 に答える
2

すべてのアプリケーションをテストするために、アプリケーションのすべての GUI 部分を他のすべての部分から抽出したい場合は、Model-View-Presenter を使用する必要があります。こことここで説明を見つけることができます。

このモデルでは、アプリケーションのすべてのサービスがプレゼンターを使用しますが、ビュー (GUI パーツ) を直接操作できるのはユーザーのみです。プレゼンターは、アプリケーションからのビューを管理しています。GUI フレームワークを変更する場合に備えて、アプリケーションから独立した GUI パーツを用意します。変更する必要があるのは、プレゼンターとビュー自体だけです。

必要な GUI テストについては、プレゼンター用の単体テストを作成するだけです。GUI の使用をテストする場合は、統合テストを作成する必要があります。

それが役立つことを願っています!

于 2010-01-17T19:43:25.113 に答える
1

これまで言及されておらず、実際には質問に答えていませんが、非常に重要な 1 つのポイント:リファクタリングを開始する前に、可能な限り、今すぐテストを行う必要があります。テストの主なポイントは、何かを壊したかどうかを検出することです。

リファクタリングは、ある操作の結果がどこで変更され、同じ呼び出しが別の結果を生成するかを正確に確認することが非常に重要です。それがこのすべてのテストの目的です。何かを壊したかどうか、意図しない変更をすべて確認したいのです。

したがって、リファクタリング後も同じ結果が得られるはずのすべての部分について、今すぐテストを行ってください。テストは、永遠に同じままである完璧なコードのためのものではありません。テストは、変更が必要なコード、変更が必要なコード、リファクタリングされるコードのためのものです。テストは、リファクタリングが本当に意図したとおりに行われることを確認するためにあります。

于 2010-01-28T02:03:35.867 に答える
1

以前、UI とバックエンドの分離を目的とした大規模なレガシー コードのリファクタリングを行ったことがあります。楽しくてやりがいがあります。

/賞賛 ;）

どのパターンを呼び出しても、MVC の一部であっても、非常に明確なAPI レイヤーを持つことは非常に重要です。可能であれば、UI <-> Logic 通信をより細かく制御できるディスパッチャーを介してすべての UI リクエストをルーティングできます。キャッシング、認証などの実装

視覚化するには:

[QT Frontend]
[CLIs]             <=======> [Dispatcher] <=> [API] <==> [Core/Model]
[SOAP/XMPRPC/Json]
[API Test Suite]

こちらです

  • テスト スイートを追加して API をテストする方が簡単です。
  • また、より多くの UI を均一な方法で簡単に追加できます。
  • API ドキュメンテーション: いくつかの RPC インターフェイスを介して API をドキュメント化して公開したい場合、API ドキュメンテーションを生成する方が簡単です。誰かが API ドキュメントの重要性に同意しない場合は、いつでも Twitter API を見ることができ、それは成功です。
  • APIレイヤーをPythonシェルにすばやくインポートして、それで遊ぶことができます

API レイヤーのコーディングを開始する前に、API の設計を行うことができます。アプリケーションによっては、zinterfaces などのパッケージを利用したい場合があります。これは、非常に小さなアプリを作成している場合でも、私がとる一般的なアプローチであり、失敗したことはありません。

見てください

このアプローチの明確な利点の 1 つは、API レイヤーと新しい UI を作成した後、レガシー コードに戻って、おそらくより小さなステップで修正/リファクタリングできることです。

その他の提案は、テスト スイートを用意することです。ブラウンフィールド アプリケーションでユニット テストを実装するための最初のタスクは何ですか?で interstar のアドバイスを参照してください。.

于 2010-01-27T11:02:16.240 に答える