したタイミングで、指定された設定ファイルに従って実行するかどうかを決定します。ブランチ用のプロジェクトでは初期設定が利用されます。実行結果も反映される事となりました。ブランチ以外の実行を防止するように設定しています。サービスと連携して利用されます。テストが実行されたかどうかを確認する事ができると言う点です。カバレッジが未達成)のままな事があります。チェックは不要なのではないか?」と言う可能性についても検討します。このように、自分のプログラムを行単位でテストが実行されているかどうかを定期的に確認すると言う行為が、セルフ・コードレビューのような機能も果たす事が分かりました。ような値をどう捉えるかに関しては、当初よりもかなりポジティブな印象を抱いています。対応する文字列を取得する」ような単純なメソッドのテストコードに対しては、長らく「このテストに、カバレッジの数値を上げる以外の意味があるのだろうか?」と言う疑問を抱いていました。よる思わぬバグを早期に発見できた言う経験が何度もあり、一見すると無駄に見えるテストの重要性を実感するようになりました。カバレッジの数値を上げるためだけの近視眼的なテストコードを記述する事によって、それよりも重要なテストコードを見逃すのではないかと言う不安は依然としてあります。最近は、ある程度は仕方がないと割り切り、以下のような指針で実装およびテストコードの記述を行っています。程度)を指標としてテストコードを記述する。この結果、初期リリース時点では、正常ケースおよび容易に予想可能な異常ケースのテストに留まる。リリース後に何らかの不都合が発覚した場合、必ず最初に該当の不都合が再現するテストコードを記述する。テストを実行してレッド・シグナルを確認する。該当部分の実装コードを修正し、テストを実行してグリーン・シグナルを確認する。このサイクルによって、完全ではないにしても「少しずつだが、良くなってはいる」事を実感できるのは、テストコードを含めた保守を続けていく、あるいは習慣化する上でプラスに働いていると思います。サービスと連携して利用する事がほとんどです。連携方法について記載します。項目でテストを実行します。利用しており、具体的な記述例は下記のようになります。含める必要があります。つのファイルに纏める事ができます。このオプションがない場合、テストが失敗した場合であっても正常終了したと見なされるようになります。送信されてカバレッジの推移が見づらくなると言う問題が発生しました。送信する設定は上記のようになります。必要ないようです(ローカル環境からアップロードしようとした場合は必要)。上で閲覧する事ができます。プロジェクトには適用できませんでした。統合できるかもしれません。存在を知ったのは数ヶ月前の事で、まだそこまで使いこなせている訳ではないのですが、なかなか良い感触を得たため、自分のプロジェクトに対して順次適用しています。人で開発を行っているとコードレビューを行う人がそもそも存在しないため、定期的なセルフ・コードレビューを意識する必要があります。この課題を補う方法の一つとして機能していると感じます。