Javaにおけるロギングとデバッグのガイド
Article by: Abdul D なぜロギングとデバッグが重要なのか？ プログラムの開発中、プログラムの実行フローを追跡し、コード内の問題を特定するために、単純な println() ステートメントを使っているかもしれません。しかしプロジェクトが大きくなり、複雑になるにつれて、プリント文はすぐに散らかってしまいます。プログラムの実行を追跡するためのより良い方法はロギングです。ロギングはアプリケーションの動作を一貫して整理された方法で追跡する手段を提供し、問題を体系的に特定し、解決できるようにします。 このガイドでは、Java でのロギングの設定方法、基本的なデバッグツールを効果的に使用する方法、そして安定した保守可能なアプリケーションを作成するためのベストプラクティスについて探ります。 また、Sentry が Java アプリケーションでエラーを監視し管理する手助けをどのようにするかについても見ていきます。基本と合わせて、高度なテクニックを理解することで、Javaプロジェクト内の問題に自信を持って取り組むための準備が整います。 Java でロギングを設定する方法 もしかするとコードのロギングとデバッグのために System.out.println() を使用したことがあるかもしれません。 次のように出力されます。 Debugging: Starting the programDebugging: Result is 8 このようなコンソールロギングは、小規模なプロジェクトや簡単なテストには役立つことがありますが、いくつかの制限があります。保存されていないコンソールログはプログラムが停止すると消えてしまい、何が起こったのかの履歴を保持することが難しくなります。また、ログメッセージを重要度別に分類することができず、出力結果で重要な問題を見逃しやすくなります。 Javaでの基本的なロギングは、組み込みの java.util.logging パッケージを使用することで実現できます。この組み込みフレームワークを使用すると、アプリケーション内で情報メッセージ、警告、エラーなど、さまざまなイベントを簡単に記録して出力できます。 java.util.logging を使用すると、各メッセージの重要度を示すためにログレベルを指定できます。 SEVERE：アプリケーションが正しく動作しない可能性のある重大なエラーを示します。 WARNING：注意が必要な潜在的な問題を示します。 INFO：アプリケーションの実行進行状況に関する一般的な情報を提供します。 CONFIG：設定関連のメッセージを示します。 FINE, FINER, FINEST：デバッグ目的で詳細な情報を提供します。 これらのログレベルは次の構文を使って使用できます。logger.<LEVEL>(“<YOUR_MESSAGE_HERE>”) ロギングを有効にするには、module-info.java ファイルに以下を追加する必要があるかもしれません。 requires java.logging; 以下はロガーを設定し、異なるレベルでメッセージをログに記録する方法です。 以下が出力されます。 ロギング例の出力 ログメッセージがタイムスタンプで記録され、ログステートメントが呼ばれたクラス名とメソッド名が含まれている点に注目してください。この情報は、複雑なアプリケーションでバグを追跡する際に非常に貴重です。 Javaでのログレベルの設定 上記の例では、INFO、WARNING、SEVEREメッセージのみがログに記録され、CONFIG と FINE メッセージは記録されていないことに気付くかと思います。 これはデフォルトのログレベルが […]
【Visual Studio App Centerが廃止】次に Sentry を勧める理由を解説
Article by: Sarah Guthals Visual Studio App Center が廃止されることは以前から知っていました。正式な廃止日が2025年3月31日と発表され、いよいよカレンダーを見ると2025年。そろそろ App Center の代替案を選定し、他のツールへの移行準備を本格的に進めるべき時期が迫りました。 *なお、Microsoft は App Center Analytics & Diagnostics 機能に限り、製品サポートを2026年6月30日まで延長する予定です。ただし App Center の他の機能については 2025年3月31日で提供が終了します。移行には綿密な計画と手間がかかりますので、早めに対応を進めることをおすすめします。 この記事ではスムーズな移行に役立つガイドをお届けします。他の参考リソースへのリンクも盛り込んでいますので、ぜひご活用ください。 Visual Studio App Center からの移行方法 Visual Studio App Center にはモバイル開発者がよく利用していた5つの主要な機能がありました。それはクラウドベースのビルド、デバイステスト、配布、コードプッシュ、そして分析＆診断です。 これらの機能にはそれぞれ推奨される代替ツールがありますが、チームにとってどのツールが最適かを慎重に見極めることが重要です。機能の違いはもちろん、ツールの互換性、API や拡張性、さらにはユーザーエクスペリエンス（UX）も移行のしやすさを大きく左右します。 以下では、App Center の各機能ごとに推奨される代替ツールをご紹介します。 クラウドベースのビルド：App Center では、iOS や Android アプリをクラウド上でビルドいる機能が提供されていました。 代替として、Ionic をおすすめします。Ionicは、Cordova や Capacitor、React Native といったフレームワークで開発されたアプリを複雑な手順を踏むことなく、iOS および […]
SentryのRollback、Hack Week発のプロジェクトが本番稼働へ
Article by: Malachi Willey ❗❗もしあなたが Sentry を使っていて、今が2024年なら、今すぐ読むのを止めて、まずは rollback.sentry.io にアクセスしてみてください。自分専用のRollbackが手に入ります！ ほんの数週間前、私たちは Sentry Rollback という機能をリリースしました。 これは Sentry で初めてとなる「年次レビュー体験」です。 イメージとしては、Spotify Wrapped（Spotifyが毎年行っているユーザーの音楽の好みをハイライトする機能） の開発者版のようなもので、Sentry を通して過ごした1年を振り返ることができる独自の機能です。 見た目はスタイリッシュで、ちょっと（というか、かなり）皮肉も効いています。あなたの成果をしっかり称えながら、ついでに失敗も軽くあざ笑います。成功というのは、失敗の上に成り立ちますからね。 Rollback の起源は少しユニークです。最初は社内向けに「何か面白くて笑えるものを作ろう」という軽い気持ちからスタートしました。しかしそれが、気が付けば本格的なプロジェクトに成長していました。今回は、その歩みをご紹介していきます。 クエリ結果が得られないことに何度も悩まされたのではないでしょうか。私たち自身もその例外に何度も頭を抱えた結果、ついに修正することに踏み切りました。 始まり：Rollback のアイデア誕生 毎年、Sentryでは社内ハックウィークを開催しています。これは Sentry 社員全員が普段の業務から離れ、自分の「作りたいもの」に自由に取り組む1週間です。ルールは「何を作ってもOK」ただ一つ。「こんなものがあったらいいのに」と思ったら、それを作るだけです。 多くのハックウィークのプロジェクトは、その週が終わると役目を終えますが、中には社内で使い続けられるものもあります。そして時々、本番環境に飛び込すプロジェクトが生まれることがあります。Sentry Rollback はその一つでした。 チーム編成から始まった Rollback ほとんどのハックウィークのプロジェクトは、エンジニア同士が数人集まってチームを組んで進めます。同じチーム内で完結することも少なくありません。 しかし、Rollback は違いました。エンジニアリング、プロダクト、マーケティング、デザイン、さらにはセールスコピーまで、社内全体から人が集まり、Sentry 全体で取り組む「全社プロジェクト」となったのです。 多様な視点が加わったことで、Rollback はごく初期の段階から「まるで本物のSentryの製品（TM）」のような完成度を見せはじめました。なぜなら、必要な要素がしっかり揃っていたからです。 出荷とクラッシュ、そして再スタート… Rollback Rollback を他の年次レビューと差別化するため、まず取り組んだのは名前を決めることでした。私たちはあまり堅い印象になりすぎないようにしているので、ちょうどいいユーモアのある名前が必要だと考えました。 利用者ターゲットの99%がエンジニアのため、開発者の心に響く名前でなければなりません。Sentry Replay、Sentry Shipped、Sentry Wreckedなどのアイデアが出ましたが、最終的に「Rollback」に決定しました。 「Rollback」という名前は、まるで過去に戻って1年分のバグを再体験するようなイメージを呼び起こします。開発者がひと目見て、直感的に理解できるネーミングです。 今年、あなたも一度は“ロールバック”したのではないでしょうか？私たちはもちろんしましたよ！ MVPを最速で作ることから始める ハックウィークの限られた数日間で、Rollback のような体験を作るのは簡単なことではありません。 プロジェクトはチームを跨いで関わる部分も多いため、綿密な進行管理が必要でした。プロダクトマネージャーは、優先順位を理路整然と決め、初期のデザインやワイヤーフレームといった障害になりそうな要素を排除していきました。その結果、対象スコープも最小限になりました。 ハックウィーク版では、Sentry の従業員のために動作することだけに焦点を当てました。複雑なインフラ構成は避け、データベースも使わず、パフォーマンス最適化に悩む必要性もなくしました。ひたすらコンセプトの実証だけに集中し、クスッと笑える動作を目指しました。 ハックウィークの優勝者 […]
Sentryを活用したクエリのレート制限のデバッグ方法について
Article by: Rachel Chen Snubaは、Sentryを本番環境で動作させるための中核となるイベントデータの保存およびクエリサービスです。 これまで内部でレート制限を行っていたため、その挙動が見えづらく、サポート対応に時間がかかるケースがありました。Snubaのコードに精通していない限り、こうした詳細にはなかなか気づけません。 しかし、実際に顧客からの問い合わせを整理していく中でよく見かける問題が1つありました。それが「RateLimitExceeded」です。 クエリ結果が得られないことに何度も悩まされたのではないでしょうか。私たち自身もその例外に何度も頭を抱えた結果、ついに修正することに踏み切りました。 SentryがRateLimitExceededの問題を抱えていた理由 Sentry では、社内で運用している複数の ClickHouse クラスタを利用しています。 これらは、UI や API のデータ提供を担っています。また、ClickHouse リソースをどのように割り当てるかを決定するために「ClickHouse 容量管理システム」の中で割り当てポリシーのコレクションを用意しています。 Snuba にクエリが送信されると、容量管理システムがこれらのポリシーを適用し、クエリを受け入れるか、拒否されるか、あるいはスロットル（処理の一時的な遅延）するかを判断します。 Sentryが全体のレート制限をどのように改善したか まずレート制限の仕組みをより明確に把握するため、Sentry のエンジニアたちがクエリ状況を確認できる「Snubaカスタマーダッシュボード」をインフラツール内に構築しました。 そしてこの取り組みによって、エラー関連のクエリが 96.628% の成功率であることがわかりました。 しかし、単に成功率を知っているだけでは、根本的な解決にはなりません。Datadog のようなインフラ監視ツールは非常に有用ですが、デバッグには向いていないためです。 そこで「私たちはそもそもデバッグツールを作っているのだから（それが Sentry です 😃）、この情報をSentry上で見られるようにしよう」と考え、実際にそうしました。 ステップ1: 開発者ワークフローの改善 まず Sentry に新機能を追加する前に、必要な情報が揃っていることを確認しました。 最初に Snuba カスタマーダッシュボードを使って全体の概要（何が起きているのか）を把握し、次に Sentry のトレースビューページでレート制限されたクエリの詳細（なぜ起きたかとどのように起きたか）に掘り下げます。 以下は、api.project-events リファラーから、拒否されたクエリを含むすべてのトレースを取得する例です。 ステップ2: クエリが拒否される前に「警告ゾーン」で知らせる […]
【VSCode + Sentry】Pythonのデバッグを快適にする方法
Article by: David Y. Sentry は開発者がバグのあるコードを迅速かつ効果的に修正できるよう支援しています。この記事では、VSCode と Sentry Python SDK を活用し、Python コードをデバッグするための中級から上級レベルのテクニックを幅広く紹介します。 Python デバッグの例 デバッグを行うには、まずバグのあるコードが必要です。 そこで今回は短い Python スクリプトを用意しました。このスクリプトは、外部の JSON ファイルからユーザーデータを取得し、内部のデータ構造に格納するといったものです。 こうしたコードは、メールニュースレター管理ツールにユーザーアカウントをインポートする際にも利用されることがあります。 このコードは、小規模で完璧にフォーマットされた users.json を使用した単純なテストケースで正常に動作します。しかし、管理されたテスト環境を離れると例外が発生する可能性が出てきます。考えられる失敗パターンは以下のとおりです。 users.json が存在しない users.json に無効な JSON が含まれている 一部のユーザーに必要なフィールドが欠落している 一部のフィールドのデータ方が想定と異なる 以下のセクションでは、さまざまなデバッグ環境を使用し、これらのケースを調査していきます。 実際に試しながら進める場合は、上記のコードをコピーしてシステム上の空のディレクトリに users.py というファイル名で保存してください（users.json は後ほど作成します）。 VSCode で Python をデバッグする方法 VSCode は、Python を含むさまざまなプログラミング言語で使用できるグラフィカルなデバッグインターフェースを提供しています。 まだ VSCode をインストールしていない場合は、こちらでインストールファイルと手順を確認できます。 以下では、VSCode のデバッグ機能をセットアップし、Python スクリプトをデバッグする方法 […]
Next.jsのデバッグ手法はどうしたらいい？開発から本番公開までの実践的ヒントを解説
Article by: Matt Henderson, Sarah Guthals デバッグ… それはすべての開発者にとって必要不可欠なスキルです。Next.js を使って動的で高性能なアプリケーションを構築する際、Chrome DevTools や console.log() だけでは対応しきれない場面もあります。またアプリケーションが成長していくにつれて、より効果的で体系的なデバッグ手法が求められるようになります。 今回の記事では Next.js のデバッグワークショップで紹介した実践的なヒントを交えながら、開発段階から本番環境まで役立つデバッグ手法をご紹介します。 今回は Next.js に特化した内容ですが、React アプリのデバッグについてもこちらで紹介しています。ぜひご一読ください。 効果的な Next.js のデバッグツールとテクニック デバッグはエディタでコードを書きながらローカル環境でテストしている段階から始まります。 まずはそこから解説していきます。そして最終的には、本番環境にデプロイされた後、開発チームではなく実際のユーザーがバグを発見するような場面でのデバッグ方法まで理解できるようになるはずです。 1. React Developer Tools を活用する Next.js は React を基盤としたフレームワークであり、幸いなことに React Developer Tools を使えば、コンポーネントの階層や props、state を直感的に確認できます。React DevTools を活用すると、以下のようなことが可能になります。 ・コンポーネントツリーを視覚的に把握できるため、動的ルーティングやサーバサイドレンダリング（SSR）を使用しても階層構造を理解しやすくなる ・リアルタイムで state や props を解析、編集を行える ・再レンダリングのトラッキングが可能になる ・React Suspenseの遅延読み込みの挙動を可視化できる […]
インデックス不足でDBが遅い… Sentryで問題を見つけ修正する方法とは？
Article by: Will McMullen 遅いデータベースクエリは、開発者にもユーザーにも悪影響を及ぼします。 リソースを浪費し、テストの遅延を引き起こし、動作が重くなることによってユーザーは不満を抱きます。しかし、多くの場合、驚くほど意外な解決策があります。それがインデックスです。 ここでは、インデックスの仕組みと、その活用タイミングについて解説します。 スキーマの種類を問わず役立つ内容です。 すでにインデックスの基本と使い方を理解していて、遅いクエリの監視やデバッグ方法を知りたい場合は実践例をご覧ください。 インデックスとは？ インデックスとは何かご存じですか？ 簡単にいえば、データベースの「GPS」のようなものです。 インデックスがないと、データベースは全ての行（レコード）を1つずつチェックしながら探し回らなければなりません。そうするとまるで迷子の観光客のように、目的地へ辿り着くまでに時間がかかってしまいます。 しかし、インデックスがあれば無駄な回り道をすることなく、一直線でユーザーの目的地（ここでいう処理）へ辿り着くことができます。 インデックスを技術的に解説すると、カラムの値を行にマッピングする小さなデータ構造のことを指しており、検索を高速化する役割を果たしています。 例を見てみましょう。 ユーザーテーブルやコレクションからメールアドレスを検索する場合、SQLデータベースではメールカラムに対するインデックスを次のように作成できます。 MongoDBやその他のNoSQLのドキュメント型データベースも、同様の方法でインデックスを活用します。例えば以下のコードのように、MongoDBではusersコレクションのemailフィールドを検索する際にインデックスを利用できます。 インデックスは決して魔法のように万能ではありません。アルゴリズムの観点では、まるで魔法のように感じられることがあります（バイナリ検索木やハッシュマップを思い浮かべてください）。 クエリがインデックス付きのフィールドを含む場合、データベースはテーブル内全ての探索を回避し、インデックスを使って効率的にデータを探します。これにより、クエリ速度が大幅に改善するのです。 インデックスは万能ではないことを理解し、適切に使わなければ逆効果になることもあります。 以下がその例の一部です。 ・書き込みの遅延 データを追加・更新するたびにインデックスも更新されるため、書き込み処理が遅くなる ・ストレージの増加 インデックスを保持するための追加のストレージが必要 ・パフォーマンスの低下 インデックスを増やしすぎると、データベースの最適化ツールが適切なインデックスを選びにくくなり、かえって処理が遅くなる それでは次に、インデックスを適用すべきケースを具体的に見ていきましょう。 SQLとNoSQLにおけるインデックスの使いどき すべてのカラムやフィールドに、インデックスを付ければよいわけではありません。 データベースへの負荷を抑えながら最適なパフォーマンスを得るには、インデックスの効果が最も大きい箇所に焦点を当てることが重要です。 どこにインデックスを適用すべきか、この後の内容を踏まえて検討してみましょう。 SQLで一般的なインデックス 主キー(Primary Key) 各テーブルには、一意の識別子となる主キー（例：id）があります。ほとんどのデータベースでは、主キーに対して自動的にインデックスが作成されるため、最も高速にデータを検索できます。 外部キー(Foreign Key) テーブル同士を関連付けるキー（例：注文テーブルと顧客テーブルを結びつける customer_id など）のことです。 これらのフィールドにインデックスを設定すると、JOIN処理のパフォーマンスが大幅に向上します。 フィルター付きカラム WHERE・ORDER BY・GROUP BY などのフィルター条件に頻繁に使うカラムは、インデックスを設定することで検索速度を向上できます。例えば、次のSQLクエリをご覧ください。SELECT * FROM products WHERE category […]
セッションリプレイ機能で、デバッグをさらに正確かつ迅速にする方法
Article by: Sarah Guthals 開発者なら誰しも、デバッグに時間がかかることを痛感した経験があるでしょう。 なかなか再現できないバグを追いかけたり、あいまいなユーザー報告を頼りに問題を特定しようとしたりすると、シンプルな修正のはずが何時間もの作業になってしまうこともありますよね。 ログやメトリクス、トレースを活用すれば原因の特定に役立ちますが、それだけではユーザーへの影響を正確に把握するのは難しいものです。 そこで役立つのがセッションリプレイです。 ユーザーセッションをビデオのように再生できるこのツールを使えば、デバッグ効率が飛躍的に向上します。ユーザーからの報告を待つ必要も、あいまいな再現手順に振り回されることも、すべての環境を完璧に再現する必要もありません。 セッションリプレイを使えば、「どこで」「何が起こったのか」を正確に把握することが可能です。 この記事では、Sentryのセッションリプレイの仕組みと、それがどのようにデバッグの効率化、ユーザーとのやり取りの削減、さらにはアプリケーションのパフォーマンス向上に役立つのかを詳しく解説します。 セッションリプレイとは？ もし、ユーザーがアプリを操作する様子をリアルタイムで映像として確認できたらどうでしょうか？ クラッシュやパフォーマンスの問題が発生するまでの流れを、正確にたどることができたらどうでしょうか？ セッションリプレイは、まさにそのための機能です。 ユーザーのクリック、スクロール、入力操作などを記録し、それをネットワークアクティビティやコンソールログ、エラーの詳細、さらにはCore Web Vitalsとあわせて表示します。 これにより、問題発生までの流れを可視化し、トラブルシューティングの際の「推測」をなくすことができます。 従来のデバッグ手法であるスタックトレースやログは、バグの再現や原因の特定に必要な情報をすべて提供できるとは限りません。特に、問題の発生状況が不明確な場合、それだけでは十分なコンテキストを得るのが難しいこともあります。 セッションリプレイを活用すれば、ユーザーがどのような操作を行い、それに対してアプリがどのように反応したのかを視覚的に確認できます。そのため推測に頼ることなく、より素早く正確に問題の原因を特定できます。 なぜセッションリプレイを活用すべきなのか セッションリプレイの利点は、開発者のワークフローやチームの体制、ユーザーの特性、アプリケーションの種類によって多少異なります。 しかし、デバッグの効率化やユーザー体験の向上といった点で、どんな開発環境にも共通して有益なメリットがいくつかあります。 デバッグ効率を飛躍的に向上させる エラーレポートを受け取った際、詳細を確認するために何度もユーザーとやり取りをした経験はありませんか？ 問題の説明を詳しく聞いたり、スクリーンショットを依頼したり、ネットワークログを取得してもらったりするのは、開発者・ユーザー双方にとって大きな負担となります。 セッションリプレイを使えば、こうした手間を省くことができます。 ユーザーが問題を報告する前の段階から、エラーが発生するまでの操作をビデオのように正確に再現できるため、原因を素早く特定し、スムーズに修正作業に取り掛かることが可能なのです。 さらに詳しく セッションリプレイを活用して、ユーザーの追加情報なしで問題を解決する Next.jsのデバッグでAPIの読み込み時間を短縮し、より快適なユーザー体験を提供 再現が難しい複雑なバグにも対応可能 バグの再現は、特に発生頻度が低いものほど厄介な存在です。 フロントエンドとバックエンドの複雑な連携によって発生する問題は、一つひとつの要因を切り分けて特定するのに数時間かけてしまうことも珍しくありません。 Sentryのセッションリプレイを活用すれば、これらの問題が発生した瞬間をリアルタイムで自動記録できます。どのUI操作がバックエンドのエラーやAPIリクエストの失敗につながったのかを正確に把握できるため、無駄な試行錯誤を減らし、迅速に修正へとつなげられます。 さらに詳しく セッションリプレイの機能強化: バックエンドエラーの導入 エンドツーエンドの可視化を実現 Sentryのトレース機能と組み合わせることで、セッションリプレイはフロントエンドのクリックからバックエンドのAPIコールまで、処理の流れを可視化します。 例えば、APIのレスポンスが遅くてユーザー体験に影響を与えている場合、セッションリプレイを使えば、ユーザーがその影響を受けた正確なタイミングを特定できます。 さらに、Sentryのネットワークトレースを活用すれば、サーバーの応答遅延や設定ミスによるエンドポイントの問題などを素早く特定でき、迅速な対応が可能になります。 さらに詳しく 開発者向けセッションリプレイ: より速いトラブルシューティングへの近道 ユーザー体験の向上をサポート バグを素早く修正するだけでなく、問題が広がる前に先手を打つことも重要です。 セッションリプレイを活用すると、ユーザーがどのようにアプリを操作しているのかを把握でき、特定の操作で行き詰まったり、パフォーマンスの問題に直面したりしている箇所を可視化することが可能です。 こうした問題を事前に修正することで、ユーザー体験を向上させ、アプリの継続利用につなげることができます。 さらに詳しく セッションリプレイを使って複雑なスタックトレースをデバッグする […]
手遅れになる前に！不安定なテストを見つけて対策する方法
Article by: Artem Zakharchenko この記事は、JavaScript用のAPIモックライブラリ「MSWJS」の作成者であるArtem Zakharchenkoによるゲスト投稿です。彼はEpicWebや自身のブログでも、テストに関する記事を執筆しています。 テストの不安定さ（フレーク性）は大きな課題です。 検出して修正するには膨大な時間がかかるだけでなく、テストの最も重要な価値である「信頼性」を損なう原因にもなります。信頼できないテストは、存在する意味がありません。そのメンテナンスに費やす時間も、結果的には無駄となってしまい、本来なら開発に充てられたはずの貴重な時間までも奪ってしまいます。 私はこれまでに、フレークテストへの対処法をご紹介してきましたが、今回はその根本原因である「不安定なテスト（フレークテスト）をいかに見つけるか」についてお話ししていきます。 フレークテストの根本原因 テストを重ねる中で学んだことの一つに、「テストの不安定さはシステムのあらゆる層に潜んでいる」ということです。テストの書き方、セットアップの方法、使用しているツール、さらにはそれらを実行するハードウェアに至るまで、どの部分にも問題の種は潜んでいます。 エンドツーエンド（以降、E2Eと表記）テストが特に不安定だと言われるのは、決して偶然ではありません。システムの端から端まで、多くの要素が絡み合うため、どこで問題が発生してもおかしくありません。それに加えて、E2Eテストはメンテナンスコストが高く、チームの誰もが対処をためらうような厄介な存在になることも多くあります。 さらに厄介なのは、フレークテストの「たまに失敗する」という性質が、問題の深刻さを見落としやすくすることです。複数の層が関わっていると、「たまたまどこかで問題が起きただけ」と片付けてしまいがちです。「再実行」ボタンを押してテストが通れば、それで良しとしてしまうことも少なくありません。 残念ながら、ほとんどのチームは初期のフレークテストをこうして放置します。 一度無視し、二度無視し、気づけばCIの結果に一喜一憂しながら、テストが緑になるまで再実行を繰り返す。そんな状況に陥ってしまうのです。 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 E2Eテスト自体を諦めてしまったチームと話したことがあります。最終的に、テストスイートの信頼性が失われてしまったことが原因でした。 しかし、本来の自動テストはそうあるべきではありません。 フレークテストに対処する方法 大規模なチームでは、特にフレークテストの問題が見過ごされることがあります。 そもそも、自分がそのテストの不安定さに直面していないかもしれませんし、何度も再実行する必要がない場合もあります。影響を受けているチームメンバーも、「仕方がないもの」と受け入れてしまうことが少なくありません。 しかし、そんなテストのフレーク性は最終的にチーム全体の生産性を低下させます。 重要なプルリクエストが、ただテストが通るまで再実行を繰り返す「リトライゲーム」のせいで滞ってしまうのは、非常に厄介です。 私自身も、そうした状況に何度も直面してきました。 だからこそ、私はビルドを常に安定させ、フレーク性を見つけ次第、徹底的に排除することに注力しています。 そのためにも、フレークテストを検出し、追跡できるツールを活用するのは非常に有効です。 最近、CodecovがTest Analyticsを発表したので、早速試してみることにしました。最も一般的なフレークテストの原因を意図的に再現し、それをどのように検出・修正できるのかを検証するのが、一番の近道だからです。 フレークテストの検出を検証する ここでは、Vitestのブラウザモードを使用して、シンプルなブラウザ内テストを実施します。 今回テストするのは、ユーザーの投稿リストをレンダリングする<App />コンポーネントです。 かなりシンプルな内容ですが、鋭い方なら既に問題に気づいているかもしれません。 しかし、もし私がそれに気づかなかったとしたら、どうでしょうか？ 私はこのテストを書き、実行し、成功を確認し、変更を承認しました。 そして今、このテストはチーム全員のメインブランチで実行される状態になっています。 ここで、テスト分析を導入してフレークテストを追跡すると、どのような影響があるのかを見てみましょう。 CodecovのTest Analyticsを導入する Test Analyticsは Codecov の一部として提供されており、フレークテストの検出機能も備えています。 公開リポジトリに対しては無料で利用でき、プライベートリポジトリでは Pro またはEnterprise プランが必要です。 プロジェクトへの統合はわずか3ステップで完了します。 Codecov […]
React Nativeの新しいデバッグ手法
これはSimon Grimmによるゲスト投稿で、SimonはGalaxies.devの創設者です。Galaxies.devでは、Simonが開発者にReact Nativeを学ぶための迅速なコースと個別サポートを提供しています。是非ご覧ください。 従来、React Nativeアプリのデバッグは、面倒な作業として開発者を悩ませてきました。開発者にとって一般的にデバッグがReact Nativeの最大の課題と考えており、これが開発時間のかなりの部分を占めていることはよく知られています。 しかし、良いニュースがあります！ この課題は、改善されつつあるということです。 React Nativeのデバッグ環境は、ここ数年で大きく変わりました。Expo はデバッグを大幅に簡単にする新しいプラグインのセットに取り組んでおり、Flipper は非推奨となり、React Nativeチームは古いツールよりも大幅に改善された新しいDevToolsに取り組んでいます。 新しいReact Native DevToolsは素晴らしいですが、それでもまだ課題がいくつか残っています。 このチュートリアルでは、React Nativeアプリのデバッグに利用できるさまざまなツールを探り、それらをどのように組み合わせて包括的なデバッグ戦略を作成するか見ていきます。 JavaScriptからネイティブコードまで全てをカバーし、アプリで何が起こっているのかを正確に把握し、すべてのエラーを追跡できるようにします。 新しいReact Native DevToolsの良い点 新しいReact Native DevToolsの特徴は、Web開発の体験に合わせていることです。 DevToolsは、（Expoプロジェクトの場合）次のコマンドを実行し、ターミナルで「j」を押すことで開くことができます。 これにより、少し馴染みのあるビューが表示されます。 主な機能は以下の通りです。 Logs: アプリからのログを表示し、フィルタリングする。 Source & Breakpoints: JavaScriptコードをデバッグする。 Components Explorer: コンポーネントの階層を可視化し、propsやstateを検査する。 さらに、Expoのネットワークタブを使用してネットワークリクエストを検査することもできます（現在はunstable(不安定)とマークされていますが、最終的にはDevToolsのコア機能となる予定です）。 React Nativeチームの努力のおかげで、新しいDevToolsは旧バージョンより大幅に改善され、非常に安定していると感じられます — しばらくしてから再接続できる機能も含まれています。 さらに、コンポーネントツリーを直接デバッグできる機能により、別のツールを使う必要がなくなり、ほとんどのReact開発者はこのようなビューに馴染みがあるはずです。 しかし、これらすべては始まりに過ぎません。チームはすでに次の機能を計画しています。 Performance panel：進行中（来年を目標にしています）。 Network panel：進行中（来年を目標にしています）。 Third party Chrome extensions（サードパーティ製のChrome拡張機能）：初期探索中。Expoと協力中（予定時期未定）。 しかし、まだいくつかのギャップがあり、最初はためらっていたものの、Reactotronは今でも重要であることに気づきました。 […]