銀河鉄道

テストすべきは境界値|バグが潜むBoundary Conditionとは

サムネイル
BoundaryCondition境界条件
The edge is scary
端っこが危ない

端っこ?

境界値っていうのよ

境界 = バグが住みやすい場所

Take special care to test boundary conditions.
境界条件をテストせよ

clean code

Boundary Condition|境界条件とは

国境をパトロールする感じ

境界値 = 端っこ
  • データの端っこ
  • 例)0件、最大値、空文字、255文字、未来日付など
    • i == 0i >= 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

シンプルなはずはない、
ってこと

Remember|端っこが危ない
  • Look for every boundary condition
    • あらゆる境界値を検討し、
  • and write a test for it.
    • しっかりテストしよう

そんなに危ないの?

そこに存在するのは
一人だけじゃないから

Bugs tend to congregate.|バグは群がる


You’ll probably find that the bug was not alone.
きっと単独犯ではない

clean code

だから安心せずに
徹底リサーチ

境界の用語

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

大変…

でも
いいこともあるの

It hits us—a sudden clarity.|視界がひらける



Complete test cases, ordered in a reasonable way, expose patterns.
テストは、パターンを明らかにする

clean code

いろんな疑問が
つながるから

  • 急に、腑に落ちる
  • 目の前がひらけたように
  • 全体像がイメージできる

端っこが教えてくれる

参考文献

  • 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.


著者

author
月うさぎ

編集後記:
この記事の内容がベストではないかもしれません。

記事一覧