新型コロナウイルスに関する情報は、厚生労働省の情報発信サイトを参考にしてください。情報を見る
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
ドキュメントを見たほうが早い
というのを最近試みている。 これまで遭遇してきた flaky test の多くは比較的単純な原因だった。コード... というのを最近試みている。 これまで遭遇してきた flaky test の多くは比較的単純な原因だった。コードを少し眺めたり、乱数が原因で落ちたテストのシード値を指定するだけで再現できることが多かったため、あまり困っていなかった。 しかし、最近遭遇したテストは、並行で実行されるテストで作られるデータと競合していたため、調査が難航していた。 周辺コードや既存のログを読んでも原因が全く分からなかったため、テストの前後で変数をダンプするログを追加して、しばらく CI の様子を観察していた。 すると、調査が一気に進み、flaky test の修正も可能になりました。 この件から、普通のアプリケーションの不具合調査の際と同じように、情報を増やすためにログを仕込むテクニックが flaly test の修正でも有効であることを認識してきた。 特に、テスト実行中だとデバッガもないので、変数の中身が出るくら