リリースは本当にメジャーであることが判明し、多くの変更があり、それらは本質的にグローバルです。 しかし、まず最初に。
なぜすべてをカットする必要があるのですか？
私が理解しているように、プロジェクトが生まれたばかりの時点での主な目標は、1C環境でユニットテストがどのように需要に対応できるかを理解することでした。 プロトタイピング段階で抽象化のレベルを考えて強調することは、非常に有望なビジネスではないことは明らかです。 プロトタイプには、このコードの弾力性はありません。 プロトタイプは、結果を破棄する必要がある実験です。
さらに、基本的なアーキテクチャは変わりませんが、開発者はある愛好家から別の愛好家に移りました。 製品の人気と私が受け取りたいものの実現により、変更を加えることはますます難しくなっています。
私はアラン・クーパーの比phorが好きです：
大規模なプログラムを作成することは、レンガの柱を構築することと比較できます。 この柱は、何千ものレンガが積み重なっています。 柱は、レンガを非常に正確に置く場合にのみ構築できます。 偏差があると、レンガが落下します。 番号998のレンガを5ミリメートル偏向させることができる場合、柱はおそらく1,000レンガに耐えることができますが、偏差が5番目のレンガにある場合、柱は3十を超えることはありません。
プロトタイプから存在したアーキテクチャは、5番目のブリックと同じ偏差でした。このため、BDDスタイルでのテスト、特にGherkinの使用など、必要な新しい機能を追加できませんでした。 1つのものを選択する必要があると考えられています。 TDDまたはBDDのいずれか。 柔軟なテストの原則に取り組んできたので、ユニットテストとシナリオテストに反対するべきではないことに気付きました。
これが、柔軟なテストマトリックスの外観です。
ユニットテストは、象限1-低レベルテストを参照します。 疎結合、柔軟、テスト可能なアーキテクチャを設計するために設計されています。 開発者にとっては、クライマーの安全ロープと同じ役割を果たします。 さらに、それらは開発とメンテナンスが非常に安価です。
シナリオテストは、象限2-より高いレベルのテストに属します。 何をする必要があるかを正しく理解する必要があります。 これは、ビジネスと開発の橋渡しであり、同じ言語を話す能力です。 有効期限が切れない素晴らしいドキュメント。 さらに、それらは作成するのにより高価で、より壊れやすいです。
私にとって、とても大きな相乗効果。 高品質のソフトウェアを作成するには、両方のアプローチを一緒に使用する必要があると思います！ 両方のタイプのテストを組み合わせることにより、回帰に対する優れた保護が提供されます。
少し先に進み、BDDスタイルのテストは新しいエンジンにまだ実装されていませんが、基盤は完全に準備されていると言います。 シナリオのテストは次のステップです。
建築
完全に再設計されています。 このツールは、はるかに柔軟で開発しやすくなっています。 これは8.5k行のコードでは処理されず、プラグインシステムを備えたカーネルになりました。 はい、はい、間違いはありません。1Cでは、プラグインによって拡張されるフレームワークを作成できます。
プラグインは「Plugins」フォルダーにある外部処理であり、次の基本インターフェースを実装します。
// { Plugin interface () = ; .("", .); .("", ().); .("", ().); (); // } Plugin interface
プラグインは識別子によってアクセスされます。例：
= .("");
カーネルの作業は、1つの関数として大まかに表現できるようになりました。
= ();
合理的な疑問が生じます：「どのような標準的なテストツリーとテスト結果？」。
正規のテストツリーを使用すると、テストメソッドの汎用「ランチャー」を構築できます。 ツリーのようなデータ構造を表します。 次のタイプのノードで構成されます。
- コンテナ-グループ化の目的で機能し、下位ノードを持つ場合があります。 コンテナについても、子ノードの処理モードを指定できます。
- ランダムな回避策-単体テストに必要であり、相互のテストの独立性を保証し、あらゆる種類の副作用を見つけることができます。
- 厳密な走査順序-シナリオテストに必要な、すべての子ノードは厳密な順序で処理されます。 さらに、この種類のコンテナには、追加のプロパティ「コンテキスト」があります。これは、子と子が読み書きできるアクセス権です。
- 要素は基本的にテストメソッドのメタデータであり、コンテキストを作成してテストメソッドを呼び出すことができます。 次の基本プロパティがあります。
- パス-テストメソッドを呼び出すことができるオブジェクトのインスタンスを作成できる文字列。
- MethodName-実行されるテストメソッドの名前。
- パラメーター-テストメソッドに渡されるパラメーターの配列。 パラメータの数とタイプは、テストメソッドのシグネチャと一致する必要があります。 パラメーター化されたテストに必要です。
正規のテスト結果はテストツリーに非常に似ていますが、実行結果に関する追加情報が含まれている点が異なります。
- コンテナの場合：
- 状態-子ノードの状態の集約の結果。
- 統計-コンテナ内のテストの総数、破損したテストの数、実装されていないテストの数、ミリ秒単位の合計実行時間。
- アイテムの場合：
- ステータス-失敗/合格/未実装/破損。
- リードタイム;
- メッセージ-テストが壊れている場合の例外のテキストが含まれています。
テスト付きの標準的な木はどこから来て、これはどのように普遍化に貢献しますか？
テストによるツリーの構築は、「ローダー」と呼ばれる特別なタイプのプラグインによって行われます。 典型的なブートローダーのシナリオ：
- ユーザーは、使用するブートローダーを選択します。
- 次に、テストシナリオを検索するパスを決定します（おそらくインタラクティブに）。 この場合、パスは選択したブートローダーが正しく解釈できる特定の行にすぎません。 たとえば、ファイルシステム内のパス、構成メタデータツリー内のパスなどです。
- 選択したパスは、テストシナリオの検索に使用されます。
- 見つかったシナリオによると、カーネルのテストツリーが形成されますが、ツリーの葉の近くのパスにはいくつかの行が示され（項目2と同様）、選択されたブートローダーが正しく解釈できます。
- テストの実行中、カーネルは対応するローダーにアクセスして、ツリーの葉のパスを解決します。
ブートローダーAPI：
関数SelectPathInteractive（CurrentPath = ""） -テストをロードするためのパスをインタラクティブに選択するためのクライアントメソッド。
関数のダウンロード（カーネルコンテキスト、パス） -テストスクリプトを検索し、標準的なテストツリーを構築します。
関数GetContextPoPath（カーネルコンテキスト、パス） -送信されたパスでテストコンテキストを受信します。
現在、3つの基本的なブートローダーが実装されています。
- ファイルローダー-epfファイルからの単体テストローダー。 ファイルシステムのファイルパスをパスとして使用します。
- ディレクトリローダー-ファイルローダーの上に構築されています。 検索パスとして、ファイルシステムディレクトリへのパスを取ります。 残りはファイルダウンローダーに完全に依存しています。
- 構成サブシステムからのローダー-ストリング表現の構成メタデータツリーをパスとして使用します。 たとえば、「メタデータ。プロセス。Test_Processing」。 テスト処理APIはファイルダウンローダーを借ります。
近い将来、Gherkin機能ファイルで動作するBDDローダーを作成する予定です。
正規のテスト結果をどうしますか？
カーネルは、テストツリーを処理してテスト結果にした後、別の特別なタイプの「レポートジェネレーター」プラグインに転送します。
レポートジェネレーターは、標準的なテスト結果を他の表現に変換します。 たとえば、現在実装されているもの：
- レポートジェネレーターMXL-レポートのmoxel形式。ツールとのインタラクティブな作業で使用されるようになりました。
- Report GeneratorJunitXMLは、継続的インテグレーション（CI）で使用されるjunit.xmlレポートです。
レポートジェネレーターAPI：
関数作成レポート（カーネルコンテキスト、テスト結果） -プラグインによって提案された形式でのレポート生成。 テスト結果は、カーネルの標準形式でプラグインに送信されます。
Show（レポート）プロシージャは、生成されたレポートをインタラクティブに表示するためのクライアントメソッドです。 プラグイン自体は、ユーザーのためにユーザーが生成したレポートを発行する必要があるかどうかを決定します。
手順のエクスポート（レポート、フルパスファイル） -主にCIの目的で使用される、指定されたパスにレポートを保存します。
役に立つ
あらゆる種類の「有用なもの」は、「ユーティリティ」プラグインタイプです。 原則として、ライブラリまたはサービス機能を実行します。 たとえば、BDDスタイルのクレームライブラリは、前回の記事で書いたBDDクレームプラグインです。 「Serializer MXL」は、データベースデータをmoxel形式に、またはその逆にシリアル化するサービスプラグインです。
あとがき
メインの開発トランクに参加する前に、ソースはこちらから入手できます 。
ここで、フレームワークが「単体テスト用の単なるツール」から「ほぼすべての可能なタイプの自動テストをカバーできるツール」に成長したと考えることができます。 モジュール式で、明らかにレイヤーに分割されており、簡単に変更および拡張できます。 現在の名前は製品の目的を伝えるのをやめたようです。 たぶん、名前を変更する時ですか？ タイトルについて良いアイデアがあれば、気軽に共有してください。