テストすべきは境界値|バグが潜むBoundary Conditionとは
作成日:2025-05-01
更新日:2025-05-04

端っこが危ない

端っこ?

境界値っていうのよ
境界 = バグが住みやすい場所
Take special care to test boundary conditions.
clean code
境界条件をテストせよ
Boundary Condition|境界条件とは

国境をパトロールする感じ
- データの端っこ
- 例)0件、最大値、空文字、255文字、未来日付など
i == 0
やi >= max
- 配列の最初や最後
- デフォルト値とnull

真ん中は安全?

だから落とし穴なの
アルゴリズムの中心は意外と合ってる
We often get the middle of an algorithm right
clean code
アルゴリズムの真ん中で安心しがち

合ってるから
疑わずに信じてしまう
- 我々は、自分を正しいと思い込みがち
- 実際は、「正しさの証明」はしてない

だから直感(intuition)は
ちょっと危険
Don’t rely on your intuition.|直感に頼るな!
The problem is that we seldom realize just how complicated correct behavior is.
clean code
正しさって、私たちが思うより複雑

シンプルなはずはない、
ってこと
- Look for every boundary condition
- あらゆる境界値を検討し、
- and write a test for it.
- しっかりテストしよう

そんなに危ないの?

そこに存在するのは
一人だけじゃないから
Bugs tend to congregate.|バグは群がる
clean code
You’ll probably find that the bug was not alone.
きっと単独犯ではない

だから安心せずに
徹底リサーチ
境界の用語
用語 | 説明 | 例 |
---|---|---|
Boundary Condition | データの端っこ | 最大・最小、配列のindex 0、ループの終了条件など |
Edge Case | the boundary values 境界値そのもの | 最大255文字、最大金額、0件など |
Corner Case | rare or extreme conditions さらに極端な例 | 空文字かつnull、全てが絵文字など |
Quirk & Exception | 言語の癖と例外 | 浮動小数点の誤差、日付計算のズレなど |

大変…

でも
いいこともあるの
It hits us—a sudden clarity.|視界がひらける
clean code
Complete test cases, ordered in a reasonable way, expose patterns.
テストは、パターンを明らかにする

いろんな疑問が
つながるから
- 急に、腑に落ちる
- 目の前がひらけたように
- 全体像がイメージできる

端っこが教えてくれる
参考文献
- Clean Code(Robert C. Martin)
- Clean Coder(Robert C. Martin)
- Clean Architecture(Robert C. Martin)
- Clean Agile(Robert C. Martin)
- The Pragmatic Programmer(Andy Hunt & Dave Thomas)
- IMPLEMENTATION PATTERNS(Kent Beck)
- Information Architecture: For the Web and Beyond(Louis Rosenfeld)
- How To Make Sense Of Any Mess(Abby Covert)
- プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則(上田勲)
- 良いコード/悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方(仙塲大也)
パトロールを

テストを深堀る
【Notes for “Boundary Condition” Article】
#Structure Intent
This article was structured to progressively define and differentiate key testing concepts—starting from “boundary condition,” then expanding into related ideas like “edge case,” “corner case,” and “quirk/exception.” It aimed to clarify their relationships while keeping each concept distinct and contextualized through concrete examples.
#Writing Design
I consciously employed a tabular format early on to visually simplify technical definitions. Each term was given clear labeling and illustrative examples, followed by descriptive paragraphs for deeper understanding. I tried to balance explanation with brevity, ensuring that even nuanced distinctions (like between edge and corner cases) remained accessible.
#SEO Awareness
I used highly relevant keywords—”boundary condition,” “edge case,” “corner case,” and “quirk”—in both headings and body text to align with search intent for software testing terminology. The URL and title also clearly reflect the core topic. However, the density of similar terms might pose SEO risks for keyword cannibalization; a future version could consider internal linking or schema markup.
This piece helped me organize abstract testing terms into a clean mental model.
This article wasn’t just written to explain — it was built to untangle the clutter of overlapping concepts.
2025-05-01
編集後記:
この記事の内容がベストではないかもしれません。
記事一覧
-
メモリとストレージ 【メモリとストレージ】プログラミングに必要な保存と計算の区別 -
Testableは検証可能 プログラミングのテストの意義を深掘る|What is testable is also verifiable. -
テストは何のため なぜテストが重要なのか|プログラミングにおける自信の意味 – Why Testing Matters -
引数をまとめたい 複数の引数をまとめて読みやすくするパラメータ•オブジェクト|Parameter Object -
変数名を考える 変数名の例|variable name -
Parallelism並列(同時処理) Parallelismとは|同時処理は並列と並行(Concurrency)がある