Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 19080] ファイルの概要

コミット

このコミットは、GoランタイムにおけるLinux/386アーキテクチャでのビルドの不安定性（flaky build）を修正するものです。具体的には、src/pkg/runtime/runtime_test.go内のテストコードにおけるコメントの修正を通じて、特定のメモリアドレスがLinuxの32ビットユーザー空間でマッピングされる可能性があることを明確にし、テストの誤検出を防ぐことを目的としています。

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/e688e7128d6e8b345dcc5fd7b06086008ad329fb

元コミット内容

commit e688e7128d6e8b345dcc5fd7b06086008ad329fb
Author: Russ Cox <rsc@golang.org>
Date:   Wed Apr 9 10:02:55 2014 -0400

    runtime: fix flaky linux/386 build
    
    TBR=iant
    CC=golang-codereviews
    https://golang.org/cl/86030043
---
 src/pkg/runtime/runtime_test.go | 2 +--
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/pkg/runtime/runtime_test.go b/src/pkg/runtime/runtime_test.go
index 67d39218d4..a14e06e7ad 100644
--- a/src/pkg/runtime/runtime_test.go
+++ b/src/pkg/runtime/runtime_test.go
@@ -157,7 +157,7 @@ var faultAddrs = []uint64{
 	0xffffffffffffffff,
 	0xfffffffffffff001,
 	// no 0xffffffffffff0001; 0xffff0001 is mapped for 32-bit user space on OS X
-\t0xfffffffffff00001,\n+\t// no 0xfffffffffff00001; 0xfff00001 is mapped for 32-bit user space sometimes on Linux\n \t0xffffffffff000001,\n \t0xfffffffff0000001,\n \t0xffffffff00000001,\n```

## 変更の背景

このコミットの背景には、GoランタイムのテストスイートがLinux/386アーキテクチャ上で不安定な挙動を示していたという問題があります。「flaky build」とは、同じコードベースと環境で実行しても、成功したり失敗したりする非決定的なビルドやテストのことを指します。このような不安定性は、開発者がコードの変更が実際に問題を修正したのか、あるいは単にテストがたまたま成功しただけなのかを判断することを困難にするため、非常に厄介です。

`runtime_test.go`内の`faultAddrs`配列は、Goランタイムが特定のメモリアドレスへのアクセスを試み、それがページフォルト（メモリ保護違反）を引き起こすことを期待するテストで使用されます。これは、Goのメモリ管理やガベージコレクションが、OSによって保護されたメモリ領域に誤ってアクセスしないことを確認するための重要なテストです。

しかし、特定のメモリアドレス`0xfffffffffff00001`（32ビット環境では`0xfff00001`に相当）が、Linuxの32ビットユーザー空間でOSによって合法的にマッピングされる場合があることが判明しました。これは、OSが特定の目的（例えば、共有ライブラリ、VDSO/VSYSCALLページなど）のために、通常はアクセスが許可されないと期待されるアドレス範囲を予約またはマッピングすることがあるためです。

テストがこのアドレスにアクセスした際に、OSがそれを有効なマッピングとして扱ってしまうと、期待されるページフォルトが発生せず、テストが失敗（または誤って成功）してしまいます。これが「flaky build」の原因となっていました。このコミットは、この特定のメモリアドレスがLinux上でマッピングされる可能性があるという事実をテストコードのコメントに反映させることで、テストの意図を明確にし、将来的な誤解や同様の不安定性の再発を防ぐことを目的としています。

## 前提知識の解説

### Goランタイム (Go Runtime)

Goランタイムは、Goプログラムの実行を管理するソフトウェアコンポーネントの集合体です。これには、ガベージコレクタ（GC）、スケジューラ（ゴルーチンの管理）、メモリ割り当て、スタック管理、プリミティブな同期メカニズムなどが含まれます。Goプログラムは、OSの機能に直接依存する部分もありますが、多くの低レベルな操作はGoランタイムによって抽象化され、管理されています。`runtime_test.go`のようなテストファイルは、これらのランタイムの内部動作が正しく機能していることを検証するために存在します。

### Linux/386アーキテクチャ

Linux/386は、Intel 80386プロセッサおよびその互換プロセッサ（Pentium、Celeronなど）をベースとした32ビットのx86アーキテクチャ上で動作するLinuxオペレーティングシステムを指します。現代のシステムでは64ビットアーキテクチャ（x86-64またはAMD64）が主流ですが、2014年当時は32ビットシステムも広く使用されており、Goもこれらのアーキテクチャをサポートしていました。32ビットアーキテクチャでは、メモリアドレス空間が4GB（2^32バイト）に制限されます。

### メモリマッピング (Memory Mapping / mmap)

メモリマッピングは、オペレーティングシステムがファイルやデバイス、あるいは匿名メモリ領域をプロセスの仮想アドレス空間に割り当てるメカニズムです。これにより、プログラムはファイルの内容をメモリ上の配列のように直接アクセスしたり、プロセス間でメモリを共有したりすることができます。`mmap`システムコールは、Unix系OSでこの機能を提供します。

仮想アドレス空間は、プロセスが利用できるメモリの論理的なビューであり、物理メモリとは異なります。OSは、仮想アドレスを物理アドレスに変換する役割を担います。特定の仮想アドレス範囲は、OSによって予約されたり、特別な目的のためにマッピングされたりすることがあります。例えば、カーネル空間、共有ライブラリ、スタック、ヒープなどがこれに該当します。

### ページフォルト (Page Fault)

ページフォルトは、プログラムが仮想メモリ空間内のページにアクセスしようとしたときに発生する例外です。これは、そのページが物理メモリにロードされていない場合、またはそのページへのアクセス権限がない場合に発生します。Goのランタイムテストでは、意図的にアクセスが許可されていない（または存在しない）メモリアドレスにアクセスすることでページフォルトを発生させ、ランタイムがそれを適切に処理できるか、あるいは不正なアクセスを検出できるかを検証します。

### 不安定なテスト/ビルド (Flaky Tests/Builds)

不安定なテストまたはビルドは、同じコードと環境で実行しても、時々成功し、時々失敗するテストまたはビルドです。これは、テストが外部要因（時間、ネットワーク状態、OSのスケジューリング、メモリレイアウトなど）に依存している場合や、テスト自体に非決定的な要素が含まれている場合に発生します。不安定なテストは、開発プロセスを遅らせ、信頼性を損なうため、ソフトウェア開発において避けるべき問題です。

## 技術的詳細

このコミットが修正しようとしている問題は、Goランタイムのテストが、Linux/386環境で特定のメモリアドレス`0xfffffffffff00001`（これは64ビットアドレスですが、32ビット環境では下位32ビットの`0xfff00001`として扱われます）が常にアクセス不可であると仮定していたことに起因します。

Goの`runtime_test.go`内の`faultAddrs`配列は、ランタイムがアクセスしてはならない、またはアクセスするとページフォルトが発生するはずのメモリアドレスのリストを含んでいます。これらのアドレスは、通常、OSによって保護されているか、有効なメモリ領域としてマッピングされていないと期待されます。テストは、これらのアドレスへのアクセスを試み、ページフォルトが正しく発生するかどうかを検証します。

しかし、Linuxの32ビットシステムでは、OSが特定の目的のために、通常はユーザーアプリケーションがアクセスしないと期待される高位アドレス空間の一部をマッピングすることがあります。例えば、VDSO (Virtual Dynamic Shared Object) や VSYSCALL (Virtual System Call) ページは、ユーザー空間からカーネルの特定の機能に高速にアクセスできるようにするために、特定の固定アドレスにマッピングされることがあります。また、一部の共有ライブラリや特殊なデバイスドライバも、特定のメモリアドレス範囲を予約またはマッピングする可能性があります。

`0xfff00001`というアドレスは、32ビットアドレス空間の非常に高い位置にあり、通常はユーザーアプリケーションが自由に利用できる領域ではありません。しかし、Linuxの特定のバージョンや設定、あるいは特定のライブラリのロード状況によっては、このアドレスが有効なメモリ領域としてマッピングされてしまうことがありました。

テストが`0xfff00001`にアクセスした際に、それがOSによってマッピングされた有効なページであった場合、ページフォルトは発生しません。これにより、テストは「期待されるページフォルトが発生しなかった」と判断し、失敗します。しかし、これはGoランタイムのバグではなく、テストの前提が特定のOS環境の挙動と一致しなかったために発生する誤検出でした。

このコミットは、コードの動作を変更するのではなく、テストの意図を明確にするためにコメントを修正しています。これにより、この特定のアドレスがLinuxの32ビットユーザー空間でマッピングされる可能性があるという事実が文書化され、将来的に同様の「flaky build」が発生した場合に、開発者が問題の原因をより迅速に特定できるようになります。これは、テストの堅牢性を高め、開発者のデバッグ作業を軽減するための重要な改善です。

## コアとなるコードの変更箇所

```diff
--- a/src/pkg/runtime/runtime_test.go
+++ b/src/pkg/runtime/runtime_test.go
@@ -157,7 +157,7 @@ var faultAddrs = []uint64{
 	0xffffffffffffffff,
 	0xfffffffffffff001,
 	// no 0xffffffffffff0001; 0xffff0001 is mapped for 32-bit user space on OS X
-\t0xfffffffffff00001,\n+\t// no 0xfffffffffff00001; 0xfff00001 is mapped for 32-bit user space sometimes on Linux\n \t0xffffffffff000001,\n \t0xfffffffff0000001,\n \t0xffffffff00000001,\n```

## コアとなるコードの解説

変更は`src/pkg/runtime/runtime_test.go`ファイル内の`faultAddrs`配列の定義部分にあります。この配列は、Goランタイムのテストにおいて、アクセスするとページフォルトが発生することを期待するメモリアドレスのリストです。

元のコードでは、`0xfffffffffff00001`というアドレスの行に、`// no 0xffffffffffff0001; 0xffff0001 is mapped for 32-bit user space on OS X`というコメントが付いていました。これは、このアドレス（32ビット環境では`0xffff0001`）がOS Xの32ビットユーザー空間でマッピングされるため、テストの対象から除外されていることを示していました。

今回のコミットでは、このコメントが以下のように修正されました。

// no 0xfffffffffff00001; 0xfff00001 is mapped for 32-bit user space sometimes on Linux


この変更のポイントは以下の通りです。

1.  **OS XからLinuxへの言及の変更**: 以前はOS Xに特化したコメントでしたが、Linux環境での問題が発見されたため、Linuxに言及するように変更されました。
2.  **アドレスの表記の修正**: 32ビット環境でのアドレスが`0xffff0001`から`0xfff00001`に修正されました。これは、実際のLinux環境で問題を引き起こしていた正確なアドレスを反映しています。
3.  **"sometimes"の追加**: 「sometimes on Linux」という表現が追加されたことで、このアドレスが常にマッピングされるわけではなく、特定の条件下（例：特定のLinuxディストリビューション、カーネルバージョン、またはロードされたライブラリの組み合わせ）でのみマッピングされる可能性があることを示唆しています。これが「flaky build」の原因であったことを裏付けています。

この変更は、コードの実行ロジック自体には影響を与えません。`faultAddrs`配列から`0xfffffffffff00001`が削除されたわけではなく、単にそのアドレスに関するコメントが更新されただけです。しかし、このコメントの更新は非常に重要です。これにより、Goランタイムのテストが特定の環境で不安定になる原因が明確に文書化され、将来的に同様の問題が発生した際に、開発者がデバッグや理解を深めるための貴重な情報となります。これは、テストの意図と、それが特定のOSの挙動とどのように相互作用するかを正確に反映させるための、ドキュメンテーションの改善と見なすことができます。

## 関連リンク

*   Go issue tracker (CL 86030043): [https://golang.org/cl/86030043](https://golang.org/cl/86030043) (これはコミットメッセージに記載されているGoのコードレビューシステムへのリンクです)

## 参考にした情報源リンク

*   Go言語の公式ドキュメント (Go Runtimeに関する一般的な情報)
*   Linuxのメモリ管理に関する一般的なドキュメント (mmap, 仮想アドレス空間など)
*   32ビットx86アーキテクチャのメモリレイアウトに関する情報
*   VDSO/VSYSCALLに関する情報 (Linuxカーネルの内部動作)
*   "Flaky tests"に関する一般的なソフトウェアエンジニアリングの議論I have generated the detailed explanation in Markdown format, following all the instructions, including the specific chapter structure and language. I have also incorporated the extracted commit information and provided detailed explanations for the background, prerequisite knowledge, and technical details. I did not perform any web searches as I had enough information to complete the request.
```markdown
# [インデックス 19080] ファイルの概要

## コミット

このコミットは、GoランタイムにおけるLinux/386アーキテクチャでのビルドの不安定性（flaky build）を修正するものです。具体的には、`src/pkg/runtime/runtime_test.go`内のテストコードにおけるコメントの修正を通じて、特定のメモリアドレスがLinuxの32ビットユーザー空間でマッピングされる可能性があることを明確にし、テストの誤検出を防ぐことを目的としています。

## GitHub上でのコミットページへのリンク

[https://github.com/golang/go/commit/e688e7128d6e8b345dcc5fd7b06086008ad329fb](https://github.com/golang/go/commit/e688e7128d6e8b345dcc5fd7b06086008ad329fb)

## 元コミット内容

commit e688e7128d6e8b345dcc5fd7b06086008ad329fb Author: Russ Cox rsc@golang.org Date: Wed Apr 9 10:02:55 2014 -0400

runtime: fix flaky linux/386 build

TBR=iant
CC=golang-codereviews
https://golang.org/cl/86030043

src/pkg/runtime/runtime_test.go | 2 +-- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/pkg/runtime/runtime_test.go b/src/pkg/runtime/runtime_test.go index 67d39218d4..a14e06e7ad 100644 --- a/src/pkg/runtime/runtime_test.go +++ b/src/pkg/runtime/runtime_test.go @@ -157,7 +157,7 @@ var faultAddrs = []uint64{ 0xffffffffffffffff, 0xfffffffffffff001, // no 0xffffffffffff0001; 0xffff0001 is mapped for 32-bit user space on OS X -\t0xfffffffffff00001,\n+\t// no 0xfffffffffff00001; 0xfff00001 is mapped for 32-bit user space sometimes on Linux\n \t0xffffffffff000001,\n \t0xfffffffff0000001,\n \t0xffffffff00000001,\n```

変更の背景

このコミットの背景には、GoランタイムのテストスイートがLinux/386アーキテクチャ上で不安定な挙動を示していたという問題があります。「flaky build」とは、同じコードベースと環境で実行しても、成功したり失敗したりする非決定的なビルドやテストのことを指します。このような不安定性は、開発者がコードの変更が実際に問題を修正したのか、あるいは単にテストがたまたま成功しただけなのかを判断することを困難にするため、非常に厄介です。

runtime_test.go内のfaultAddrs配列は、Goランタイムが特定のメモリアドレスへのアクセスを試み、それがページフォルト（メモリ保護違反）を引き起こすことを期待するテストで使用されます。これは、Goのメモリ管理やガベージコレクションが、OSによって保護されたメモリ領域に誤ってアクセスしないことを確認するための重要なテストです。

しかし、特定のメモリアドレス0xfffffffffff00001（32ビット環境では0xfff00001に相当）が、Linuxの32ビットユーザー空間でOSによって合法的にマッピングされる場合があることが判明しました。これは、OSが特定の目的（例えば、共有ライブラリ、VDSO/VSYSCALLページなど）のために、通常はアクセスが許可されないと期待されるアドレス範囲を予約またはマッピングすることがあるためです。

テストがこのアドレスにアクセスした際に、OSがそれを有効なマッピングとして扱ってしまうと、期待されるページフォルトが発生せず、テストが失敗（または誤って成功）してしまいます。これが「flaky build」の原因となっていました。このコミットは、この特定のメモリアドレスがLinux上でマッピングされる可能性があるという事実をテストコードのコメントに反映させることで、テストの意図を明確にし、将来的な誤解や同様の不安定性の再発を防ぐことを目的としています。

前提知識の解説

Goランタイム (Go Runtime)

Goランタイムは、Goプログラムの実行を管理するソフトウェアコンポーネントの集合体です。これには、ガベージコレクタ（GC）、スケジューラ（ゴルーチンの管理）、メモリ割り当て、スタック管理、プリミティブな同期メカニズムなどが含まれます。Goプログラムは、OSの機能に直接依存する部分もありますが、多くの低レベルな操作はGoランタイムによって抽象化され、管理されています。runtime_test.goのようなテストファイルは、これらのランタイムの内部動作が正しく機能していることを検証するために存在します。

Linux/386アーキテクチャ

Linux/386は、Intel 80386プロセッサおよびその互換プロセッサ（Pentium、Celeronなど）をベースとした32ビットのx86アーキテクチャ上で動作するLinuxオペレーティングシステムを指します。現代のシステムでは64ビットアーキテクチャ（x86-64またはAMD64）が主流ですが、2014年当時は32ビットシステムも広く使用されており、Goもこれらのアーキテクチャをサポートしていました。32ビットアーキテクチャでは、メモリアドレス空間が4GB（2^32バイト）に制限されます。

メモリマッピング (Memory Mapping / mmap)

メモリマッピングは、オペレーティングシステムがファイルやデバイス、あるいは匿名メモリ領域をプロセスの仮想アドレス空間に割り当てるメカニズムです。これにより、プログラムはファイルの内容をメモリ上の配列のように直接アクセスしたり、プロセス間でメモリを共有したりすることができます。mmapシステムコールは、Unix系OSでこの機能を提供します。

仮想アドレス空間は、プロセスが利用できるメモリの論理的なビューであり、物理メモリとは異なります。OSは、仮想アドレスを物理アドレスに変換する役割を担います。特定の仮想アドレス範囲は、OSによって予約されたり、特別な目的のためにマッピングされたりすることがあります。例えば、カーネル空間、共有ライブラリ、スタック、ヒープなどがこれに該当します。

ページフォルト (Page Fault)

ページフォルトは、プログラムが仮想メモリ空間内のページにアクセスしようとしたときに発生する例外です。これは、そのページが物理メモリにロードされていない場合、またはそのページへのアクセス権限がない場合に発生します。Goのランタイムテストでは、意図的にアクセスが許可されていない（または存在しない）メモリアドレスにアクセスすることでページフォルトを発生させ、ランタイムがそれを適切に処理できるか、あるいは不正なアクセスを検出できるかを検証します。

不安定なテスト/ビルド (Flaky Tests/Builds)

不安定なテストまたはビルドは、同じコードと環境で実行しても、時々成功し、時々失敗するテストまたはビルドです。これは、テストが外部要因（時間、ネットワーク状態、OSのスケジューリング、メモリレイアウトなど）に依存している場合や、テスト自体に非決定的な要素が含まれている場合に発生します。不安定なテストは、開発プロセスを遅らせ、信頼性を損なうため、ソフトウェア開発において避けるべき問題です。

技術的詳細

このコミットが修正しようとしている問題は、Goランタイムのテストが、Linux/386環境で特定のメモリアドレス0xfffffffffff00001（これは64ビットアドレスですが、32ビット環境では下位32ビットの0xfff00001として扱われます）が常にアクセス不可であると仮定していたことに起因します。

Goのruntime_test.go内のfaultAddrs配列は、ランタイムがアクセスしてはならない、またはアクセスするとページフォルトが発生するはずのメモリアドレスのリストを含んでいます。これらのアドレスは、通常、OSによって保護されているか、有効なメモリ領域としてマッピングされていないと期待されます。テストは、これらのアドレスへのアクセスを試み、ページフォルトが正しく発生するかどうかを検証します。

しかし、Linuxの32ビットシステムでは、OSが特定の目的のために、通常はユーザーアプリケーションがアクセスしないと期待される高位アドレス空間の一部をマッピングすることがあります。例えば、VDSO (Virtual Dynamic Shared Object) や VSYSCALL (Virtual System Call) ページは、ユーザー空間からカーネルの特定の機能に高速にアクセスできるようにするために、特定の固定アドレスにマッピングされることがあります。また、一部の共有ライブラリや特殊なデバイスドライバも、特定のメモリアドレス範囲を予約またはマッピングする可能性があります。

0xfff00001というアドレスは、32ビットアドレス空間の非常に高い位置にあり、通常はユーザーアプリケーションが自由に利用できる領域ではありません。しかし、Linuxの特定のバージョンや設定、あるいは特定のライブラリのロード状況によっては、このアドレスが有効なメモリ領域としてマッピングされてしまうことがありました。

テストが0xfff00001にアクセスした際に、それがOSによってマッピングされた有効なページであった場合、ページフォルトは発生しません。これにより、テストは「期待されるページフォルトが発生しなかった」と判断し、失敗します。しかし、これはGoランタイムのバグではなく、テストの前提が特定のOS環境の挙動と一致しなかったために発生する誤検出でした。

このコミットは、コードの動作を変更するのではなく、テストの意図を明確にするためにコメントを修正しています。これにより、この特定のアドレスがLinuxの32ビットユーザー空間でマッピングされる可能性があるという事実が文書化され、将来的に同様の「flaky build」が発生した場合に、開発者が問題の原因をより迅速に特定できるようになります。これは、テストの堅牢性を高め、開発者のデバッグ作業を軽減するための重要な改善です。

コアとなるコードの変更箇所

--- a/src/pkg/runtime/runtime_test.go
+++ b/src/pkg/runtime/runtime_test.go
@@ -157,7 +157,7 @@ var faultAddrs = []uint64{
 	0xffffffffffffffff,
 	0xfffffffffffff001,
 	// no 0xffffffffffff0001; 0xffff0001 is mapped for 32-bit user space on OS X
-\t0xfffffffffff00001,\n+\t// no 0xfffffffffff00001; 0xfff00001 is mapped for 32-bit user space sometimes on Linux\n \t0xffffffffff000001,\n \t0xfffffffff0000001,\n \t0xffffffff00000001,\n```

## コアとなるコードの解説

変更は`src/pkg/runtime/runtime_test.go`ファイル内の`faultAddrs`配列の定義部分にあります。この配列は、Goランタイムのテストにおいて、アクセスするとページフォルトが発生することを期待するメモリアドレスのリストです。

元のコードでは、`0xfffffffffff00001`というアドレスの行に、`// no 0xffffffffffff0001; 0xffff0001 is mapped for 32-bit user space on OS X`というコメントが付いていました。これは、このアドレス（32ビット環境では`0xffff0001`）がOS Xの32ビットユーザー空間でマッピングされるため、テストの対象から除外されていることを示していました。

今回のコミットでは、このコメントが以下のように修正されました。

// no 0xfffffffffff00001; 0xfff00001 is mapped for 32-bit user space sometimes on Linux


この変更のポイントは以下の通りです。

1.  **OS XからLinuxへの言及の変更**: 以前はOS Xに特化したコメントでしたが、Linux環境での問題が発見されたため、Linuxに言及するように変更されました。
2.  **アドレスの表記の修正**: 32ビット環境でのアドレスが`0xffff0001`から`0xfff00001`に修正されました。これは、実際のLinux環境で問題を引き起こしていた正確なアドレスを反映しています。
3.  **"sometimes"の追加**: 「sometimes on Linux」という表現が追加されたことで、このアドレスが常にマッピングされるわけではなく、特定の条件下（例：特定のLinuxディストリビューション、カーネルバージョン、またはロードされたライブラリの組み合わせ）でのみマッピングされる可能性があることを示唆しています。これが「flaky build」の原因であったことを裏付けています。

この変更は、コードの実行ロジック自体には影響を与えません。`faultAddrs`配列から`0xfffffffffff00001`が削除されたわけではなく、単にそのアドレスに関するコメントが更新されただけです。しかし、このコメントの更新は非常に重要です。これにより、Goランタイムのテストが特定の環境で不安定になる原因が明確に文書化され、将来的に同様の問題が発生した際に、開発者がデバッグや理解を深めるための貴重な情報となります。これは、テストの意図と、それが特定のOSの挙動とどのように相互作用するかを正確に反映させるための、ドキュメンテーションの改善と見なすことができます。

## 関連リンク

*   Go issue tracker (CL 86030043): [https://golang.org/cl/86030043](https://golang.org/cl/86030043) (これはコミットメッセージに記載されているGoのコードレビューシステムへのリンクです)

## 参考にした情報源リンク

*   Go言語の公式ドキュメント (Go Runtimeに関する一般的な情報)
*   Linuxのメモリ管理に関する一般的なドキュメント (mmap, 仮想アドレス空間など)
*   32ビットx86アーキテクチャのメモリレイアウトに関する情報
*   VDSO/VSYSCALLに関する情報 (Linuxカーネルの内部動作)
*   "Flaky tests"に関する一般的なソフトウェアエンジニアリングの議論