銀河鉄道

プログラミングのテストの意義を深掘る|What is testable is also verifiable.

サムネイル
Testable検証可能

Runs
All the Tests

テストって面倒…

テストの意義について
考えてみよう

Execution Strategy|テスト戦略

A system that cannot be verified should never be deployed.
検証できないシステムはデプロイすべきでない

clean code
テストのやり方
  • As frequently as possible
    • できるだけ頻繁に
  • To provide maximum feedback
    • 最大限のフィードバックを得るために
  • And to ensure the system remains continuously clean
    • 常にクリーンな状態に保つために

頻繁にやるの?

なぜなら
テストはSpecification(仕様)だから

Specification = Test|仕様はテスト

A specification is, by its very nature, a test.
仕様書とは、本質的には「テスト」のこと。

The Pragmatic Programmer

テストされた結果
ってことだから

仕様書って何?
  • The specification is true purpose of test.
    • 仕様書とは、テストの目的(結果)である

つまり、

  • Writing tests is simply the work of specifying.
    • テストを書くとは、仕様を言語化する作業である

仕様どおりに動かなければ、
仕様は仕様ではない

仕様もテストも
コミュニケーションってこと

Test = Communication|テストはコミュニケーション

The purpose of tests is communication
テストの目的は、コミュニケーションである

The Pragmatic Programmer

テストは何を伝える(コミュニケーションする)か?

テストが伝えるもの
  • When the tests for your feature pass, you’re done.
    • このテストが通ったら、「完了」

Done(完了)を伝えてくれる

だから
わかりやすいコミュニケーションが必要

Clarity and Precision|明確さと正確さ

Its key traits are:
  • Clarity and precision
    • 特徴は、明確さと正確さ

つまり、

  • Tests should be easy for people to understand
    • 人が理解しやすいもの

It’s Done なのか、It’s not done なのか
わからなければテストじゃない

わかりやすくするためには
先にやることよ

Writing Failure Cases First|失敗ケースを先に書く

失敗ケースを先に書くことの
メリットはたくさん

よくないことを防げる

By writing failure cases first, you can:
  • Clearly define how the system should behave when something goes wrong.
    • 「失敗時にどうするか」を定義できる
  • Prevent unexpected behavior or crashes
    • 「想定外やクラッシュ」を防げる
  • Ensure error handling isn’t overlooked
    • 「エラーハンドリングの抜け漏れ」がなくなる

結果的に労力が少なくなる

You can:
  • Write minimal code.
    • 最小限のコードで済む
  • Confidently refactor it.
    • 安心してリファクタリングできる
  • Iteratively validate your changes.
    • 変更を繰り返し検証できる

設計がよくなる

You can design:
  • Clear and actionable error messages
    • わかりやすいエラーメッセージにできる
  • Recovery mechanisms to handle errors gracefully
    • エラーからのリカバリができる
  • Proper logging to simplify troubleshooting
    • トラブル対応をシンプルにするログを作れる

Every time a person makes a mistake repeatedly, …
人は何度でもあやまちを繰り返すから

いつも何度でも|Always with me

Repeatable(繰り返し)
  1. Create a test that fails.
  2. Make the test pass.  
  3. Clean up the code.  
  4. Return to step 1.

So don’t look at these tests as extra work.
テストを書くのは「余分な作業」ではない!

The Pragmatic Programmer

余分だと思うから
面倒になる

用語集

日本語英語
仕様Specification
テスト可能Testable
検証可能化Verifiability
再利用可能な構造設計Reusable Structure

参考文献

  • 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の原理原則(上田勲)
  • 良いコード/悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方(仙塲大也)
Always with me

Testable

やっぱり面倒だ
さらに深堀りしてみよう


【Notes for “Testable” Article】
#Structure Intent
The article follows a logical flow from defining “testable” in software development to contrasting it with similar concepts like “verifiable.” It uses a compare-and-contrast structure to guide the reader through foundational understanding, then extends the concept into practical implications. The sequence moves from core definitions to mental shifts needed in thinking and coding practices.

#Writing Design
I aimed for clarity by keeping each concept visually separated with short paragraphs and consistent inline bolding for key terms. The use of rhetorical questions and call-and-response formatting was intended to simulate a conversational but focused tone. The repetition of parallel phrases (“Testable is not just…”) was used to drive emphasis and rhythm.

#SEO Awareness
Keywords like testable, verifiable, specification, and software design were placed in headers and body content for SEO visibility. The use of internal linking (to related articles like “early-test”) was meant to support topical authority. The headline is concise and aligns with likely search queries around software testing theory.

This piece served as both a mental anchor and a lens adjustment for how I define “testable.”
It felt like sharpening a blurry concept into a crisp outline — one paragraph at a time.


著者

author
月うさぎ

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

記事一覧