新しいプロジェクトを作成するとき、または小さなプロジェクトのバグを修正するとき、機能するものが壊れているかどうかを確認するのに問題はありません。 これを行うには、それをクリックするだけです。 しかし、これは常に発生するわけではありません。現在のプロジェクトには約200の一意のページがあり、レイアウトの回帰テストの自動化の問題に直面しています。 そして、プログラマーが長い間すべてを知っていた場合、メソッドは簡単で、対応する
ソフトウェアが書かれているので、フロントエンド開発者はそれに取り組む必要があります。 しかし、いくつかの考えがあります。
このドキュメントのコンテキストでは、すべてのレイアウトエラーを条件付きでレイアウトエラー（ドキュメント内のブロックの位置に関連する）とレイアウト（テキストの色、背景など）に分割します。次に、レイアウトエラーについて検討します。
全体の騒ぎのために
レイアウトには、オブジェクト指向
CSSのようなアプローチを使用します。 したがって、ページはブロックで構成されます。ブロックは他のブロックを含まないシンプルなもの、または内部にシンプルなブロックを含む複合物です。 コードを可能な限りカスケードしないようにしました（リンクの色、テキスト、フォントなどのいくつかの継承された値を除く）。変更を受けるブロックの9番目を慎重に行えば、何も壊れないはずです。 どんなに！ なぜなら：
- ブロックを操作した結果、変更は、このブロックを含む複合ブロック（存在する場合）およびこのブロックが含まれるページでその背後に引っ張られます。 したがって、一般的なケースでは、バグの存在が想定されます。
- ブロックを変更すると、一般的な場合、ドキュメントグリッド上のブロックの配置に違反する可能性があります。 その結果、ページを切り替えるときに同じブロックのレベルで「ジャンプ」が表示される場合があります。
- ミスは人的要因によって引き起こされる可能性があります：残念なことに、人がエイリアンではない場合があります。
- エラーには、これまで遭遇したことのない性質が絶対にあります。
いずれにせよ、1つのブロックの変更によって引き起こされるすべての変更は、当社に知られ、管理される必要があります。
原因に関係なく、最大のレイアウトエラー（できればレイアウトだけでなく）を見つけることができる汎用的な方法が必要です。アルゴリズムのアイデア
彼女はシンプルです。 概して、ドキュメントのレイアウトを変更するための唯一の客観的なマシンアクセス可能な基準は、特定のコントロールポイントの位置を変更することです。 つまり 手順は次のようになります。
- ドキュメント（シンプルブロック、複合ブロック、開発サーバー上のページのソースコード）で、いくつかのブレークポイントを設定します
- バリデータプログラムは、これらのポイントの座標系（たとえば、水平軸と垂直軸を持つブラウザワークスペースの左上ポイント）に対する座標を決定し、それらの値をデータベースに書き込みます
- 検証プログラムは、ポイントの以前の座標を現在の座標と比較し、「ページアドレス-ポイントID-古い座標-新しい座標」という形式の矛盾のリストを提供します。
- 手動モードでは、開発者はこれらのページをスキャンして、新しい値を正しい（これが加えられた変更の予期される結果に対応する場合）または正しくないとしてマークします。
したがって、開発プロセスとバグ修正の両方で同様の方法を使用できます。
バリデーターとマイルストーン
私の理解では、物理的な意味では、ドットはドキュメントコード内のテンプレートの
HTMLコメントのように見え
ます <!-- ###testing:id1### -->たとえば、
<!-- ###testing:id1### --> 。 各ページと
HTMLソースに埋め込まれたJSユーティリティを使用して、高さゼロの空のブロックに置き換えられます。 次に、このブロックの位置もJSを使用して計算されます。
ポイントは、次のロジックに従って設定されることになっています。
- ブロックソース内の1ブロックのコードの後
- 特徴的な場所のブロックコード（特定の各ケースに依存）
- 特徴的な場所のページコード、およびドキュメントグリッドの条件付きガイドの場所。
検証プログラムは、クライアント部分とサーバー部分で構成されています。 クライアントは、コメントをブロックに変換し、それらの座標を決定して、サーバー側パラメーターの値を渡します。 サーバー部分は、ポイントの値を比較し、データベースに新しいポイントを追加し、開発者による正しいポイントの選択を処理します。
まとめ
原則として、レイアウトの自動化をテストする方法があるかどうかはわかりません。 グーグルは結果を出さなかったので、私は自分の方法を考え出そうとしました。 完成したツールキットを知っている場合は、コメントで共有してください。
私は、レイアウトを実装する方法から抽象化された、したがってすべてのプロジェクトに適用できる絶対に普遍的なテストシステムに関する私の考えを形式化しようとしました。 これらはアルゴリズム自体の最初のスケッチに過ぎませんが、
ソフトウェアの操作に関しては上記の一般的な考慮事項しかありません。 私はこのアプローチに非常に忠実で効果的であると主張していません。 最初の結論は、作業の最初の結果の後にのみ引き出すことができます。
そして、最も重要なこととして、
私は一般の人々に、私が説明したすべてをコメントで話し合い、 ソフトウェアの実装を支援する愛好家だけでなく、コメントや提案をするよう促します 。
この投稿へのリンクを投稿し、ブログ、ツイートに発表を投稿し、このトピックの幅広い議論をここまたは私のブログで一般的に助けてくれるすべての人に感謝します。