Gitによる自動デバッグ

あなたのソフトウェアの複雑な部分で大きな機能に取り組んで想像してください.実装が完了し、スコープ内のすべてのテストが緑色になり、統合テストの変更をプッシュします.それから、完全に異なるモジュールからのいくつかの統合テストは失敗します.今すぐ問題を分析を開始します.あなたのコミットを手で調査することは確かに非常に退屈なプロセスで終わるでしょう.ありがたいことにgitはあなたのためにすべての作業を行うことができますが、コーヒーを楽しみながら.
ハイレベルのコマンドgit bisect それが悪い改正を見つけるためにあなたのコミット履歴をクロールしている間、自動的に指定されたテスト手順を実行することができます.

要件

手動で行うには、ローカルマシンで次の設定が必要です.

ジット

ジャバ8

マヴェン

Bash ( Windows上でのCygwin )

何がgit bisectですか？

の公式説明git-bisect documentation 州
バグを導入したコミットを見つけるためにバイナリ検索を使用します.
では、どういう意味ですか?

あなたがコミットの束を持っていると言うと、いくつかの時点で、あなたのソフトウェアは大丈夫であることを知っている.現在、あなたのソフトウェアは壊れています.そして、あなたの開発の間、どこかでバグを導入しました.何git bisect は、バイナリ検索によって選択された特定のコミットをテストすることによって、リビジョングラフを良い部分と悪い部分に分割します.テストの結果に基づいて、gitは壊れたコミットに向かって移動します.いくつかの繰り返しの後、Gitは問題を導入した改正を特定することができます.

基本的なgit bisectワークフロー

のワークフローgit bisect つの主要なステップから成ります.最初に、良いと悪いリビジョンによって制限されたリビジョンの範囲を指定する必要があります.これらのリビジョンは、リビジョンハッシュ、タグ、またはその他のGitリビジョンセレクタとして参照できます.第2に、bisectプロセスは始まります、そして、gitはテストする最初の改正のチェックアウトを自動的に実行します.テストの結果をGitに戻した後、git bisect good 成功した場合やgit bisect bad 失敗した場合は次のリビジョンが選択されます.第2のステップは、最初の壊れた改正が発見されるまで繰り返されます.

マニュアル

あなたがアイデアとワークフローについて知っている今、手で続けましょう.まずはチェックアウトrepository from GitHub サンプルプロジェクトを含む.ご覧のように、リポジトリには3つのフォルダがあります.

ケーキ工場:サンプルを見つけるいくつかの問題を含むWebブートサービス

簡単なbisect :手動でgit bisect <>を使う方法

自動化されたBisect:サンプルスクリプトを含む自動化されたbisectを使う方法

では、実行してケーキファクトリを作りましょう

mvn -f ./cake-factory/pom.xml clean install

失敗したため、ビルドが成功しなかったことを認識しますCitrus インテグレーションテスト.さて、どこでバグを紹介しましょうか.
ワークフローに示すように、最初にBIECTシナリオを設定します.したがって、我々は分析の境界を定義するために良いと悪い改正を見つけなければなりません.両方のリビジョンを見つけるのは簡単です.良い改正はあなたが分岐した改正です.悪い改正は、あなたのテストが現在失敗しているという事実のため、頭です.それにもかかわらず、私たちの例では、2つの準備されたタグを使用して、倉庫から安定して壊れます.

git bisect start # start the bisect procedure
git bisect bad broken # label the *bad* commit
git bisect good stable # label the *good* commit

または、より短いバージョンを使いたい場合は:

git bisect start broken stable # start the procedure and label the *good* and *bad* commit

さて、あなたのBisectが開始されたので、Gitはテストするコミットを選びました、そして、必要な反復の見積もりだけでなくコミットメッセージを提供します.

あなたの問題の根本的原因を特定するためのテスト戦略を考え出す必要がありました.我々の場合、統合テストは失敗しました.したがって、我々は統合テストに我々のデバッグ努力を集中しています.ケーキ工場のセットアップは、ユニットテストをスキップし、すぐにプロパティを設定することにより、統合テストを開始することができますskip.unit.test=true .

mvn clean verify -f ./cake-factory/pom.xml -Dskip.unit.tests=true

この改正では、すべてが大丈夫です、そして、ビルドは成功しました.この結果をGitに報告しなければなりません

git bisect good # tells git that the current revision is okay
#If the test would have been failed, you would have used 'git bisect bad'

我々のレポートに基づいて、Gitはチェックする次の改正を選びました.

今、あなたはテストと報告手順を繰り返す必要があります.いくつかの繰り返しの後に、問題を引き起こしている以下のコミットを見つけます.

壊れたコミットのリビジョンハッシュに注意してください.

git bisect reset

このリビジョンのコードを調べると、Cake Serviceによって配信された既定のケーキがコミットメッセージに記載されているようにバニラに変更されたことがわかりますが、統合テストは適応されていません.

自動Git bisect

あなたが認識しているかもしれないように、Bisectステップの手動実行はいくつかのオーバーヘッドを生じて、反復的な仕事です.複数のモジュールを含む複雑なプロジェクトで動作する場合、これは増加します.ありがたいことにgit bisect 特定のコマンドを実行することができるサブコマンドまたはスクリプトのテストプロシージャを自動化して結果を報告します.これは、手で手順を繰り返しながら、必要な時間だけでなく、ミスの可能性を減らすことはありません.

git bisect run <command to execute>

テストの結果をGitに報告するには、次のようなコマンドを実行します.
テストが成功した場合、実行されたコマンドはリターンコード0を出力します.
あなたがちょうどこの契約を果たす必要があるという事実のために、あなたはパイソン、あるいはJavaさえ使っているより先進のテスト・ロジックをすることもできました.それにもかかわらず、私は実用的であり、テストをシンプルに保つことを提案します.

例

練習に戻りましょう.前のセクションで既に行われていない場合は、チェックアウトしてくださいrepository from GitHub サンプルプロジェクトを含む.「自動化されたbisect」フォルダで、あなたはFindbugを見つけます.sh - bashスクリプトには、「マニュアルgit bisect」セクションからコードとしてのテスト手順が含まれます.

#!/bin/bash

mvn clean verify -f ./cake-factory/pom.xml -Dskip.unit.tests=true

今すぐ自動テストを実行するには、ちょうどBISECT環境を準備し、スクリプトを渡すgit bisect run .

git bisect start broken stable
git bisect run sh automated-bisect/findBug.sh

代わりに、Findbugのように1行のコマンドがある場合.shコマンドを直接渡すこともできますgit bisect run 渡されたコマンドが契約を満たす限り.

git bisect start broken stable
git bisect run mvn clean verify -f ./cake-factory/pom.xml -Dskip.unit.tests=true

プロセスが終了すると、Gitはマニュアル部分から知られている最初の悪いコミットを表示します.

ヒントとトリック

Git bisectとTDDについて

あなたのソフトウェアがあなたのソフトウェアを開発するためにTDDライフサイクルに続いているならば、あなたのソフトウェアがソフトウェアテスト展望から誤って機能的なsateの間で交替するので、あなたはgit bisectを使っている若干のトラブルを持つかもしれません.すぐに新しいテストを指定すると、ソフトウェアが不安定になります.あなたが簡単に実行するならばmvn clean install そのような状況ではgit bisect あなたのTDDテストによって引き起こされた失敗したビルドで混乱しているので、あなたの問題の根本原因を含んでいる改正を見つけません.これはまた、ケーキ工場の例では、削除することによって示されることができますskip.unit.tests=true Maven命令から.

git bisect start broken stable
git bisect run mvn clean verify -f ./cake-factory/pom.xml

現在git bisect 失敗するすべての単一のユニットテストに反応します.これは結果にもつながりますが、私たちが探していた問題の根本的原因とは何の関係もありません.

セットアップシナリオを賢明にテスト

「git bisectとtddについて」セクションで見たように、十分に制限がないテストシナリオでは、誤解を招く結果を返します.したがって、テストシナリオを作成することが重要です.ここでは、落とし穴を回避するのに役立つかもしれないいくつかの箇条書きのポイントです.

テストを小さくする
必要なものだけをテストし、問題に直接関係する.これは正しい結果につながるし、テストの実行時間を減らす.

あなたの依存関係を知る
失敗したテストが別のモジュールに依存している場合、開発中に変更された場合は、テストを開始する前にすべての反復処理で依存関係を再構築しなければならないことに注意してください.

自動テスト
あなたが1回以上行う場合は、それらを自動化!手動でテストを実行しないでください.それは多くの時間を消費する反復タスクです.スクリプトをテストしてみましょうgit bisect run 残りをしなさい.

一般的な“悪い”と“良い”候補を使用してください
あなたの分析のための最も効率的な境界線について考える上であなたの時間を無駄にしないでください.だってgit bisect run あなたのために仕事をします、多かれ少なかれ、1回の反復は、全く重要でありません.

悪い候補:主に頭

良い候補者:

あなたが分岐した改正

あなたのソフトウェアの最後のリリースバージョン

正常にビルドされたブランチの最後の改訂.(例えば毎晩)

概要

見たことがあるように、git bisectはあなたのGitの歴史の中で壊れたコミットを見つけるために強力なツールです.自動的にチェックされる改正の範囲を定義することができます.git bisectについてもっと知りたいなら、以下のリンクをご覧ください.

git-bisect documentation

Debugging with git

この記事は、もともとは2007年に公開されていますlabs.consol.de 2018 - 01 - 12