スキップしてメイン コンテンツに移動

投稿

ラベル(essay)が付いた投稿を表示しています

自動テストが威力を発揮するビジネス環境

はじめに 今日は、自動テストが威力を発揮する、ビジネス環境について考察したいと思います。 今までの筆者の経験から、筆者が重要だと思う「自動テストが威力を発揮するビジネス環境因子」を3つあげます。 コードベースに触るチームメンバーの人数が多い メンバーの入れ替わりが激しい コード変更を短期的に繰り返す 逆に言うと上記の3つに当てはまらない環境の場合、自動テストの導入の効果は薄いです。 つまり コードベースに触るチームメンバーの人数が少ない メンバーがほとんど入れ替われない 一度リリースしたら、コード変更はバグがあったときのみ (一回発注・納品型スタイル) の場合、自動テスト導入しても、効果は薄いと思われます。 以下、重要だと思う因子3つの根拠を記します。 3つの因子の根拠 1. コードベースに触るチームメンバーの人数が多い 当たり前ですが、関わるメンバーが多ければ多いほど。誰がどこを直したかをメンバー間で共有することは難しくなり、コードの変更管理コストも上昇していきます。Aという変更と別メンバーのBという変更が合わさったことによって、システムに矛盾した振る舞いを引き起こさせる可能性もあります。 そういった状況でも、自動テストがあれば、少なくとも現状のロジックが破壊された場合には検知してくれるので、メンバーが多くても安心して開発を進めることができます。 もちろん、対象のコードが自動テストでカバーされている + 正しいビジネスロジックのテストで網羅されているということが前提条件になります。 2. メンバーの入れ替わりが激しい メンバーの入れ替わりが激しい場合、各メンバーが保有している知識が断片的で、システム全体の知識を持っている人が少ない、あるいは全くいないということが考えられます。またメンバーの入れ替わり画激しいため、知識は容易に失われてしまう可能性も高いです。 自動テストがあれば、自分の変更が、思いがけないところでロジックを破壊していても検知できますので、安心です。 ただし、その入れ替わっていくメンバーには、そのメンバーの責任でテストを追加してもらうことが必須になります。あまり移動しないコアメンバーがいるのであれば、そのコアメンバーがテストコードを書くほうが望ましいです。コア

BDD (Behavior-driven Development) について

最近BDD (Behavior-driven Development) についてエンジニア仲間で話題になったので、記事を書こうと思い立ちました。 結論から言うと、筆者は、BDDには懐疑的な立場です。 BDDとは(あくまで筆者の理解) BDD (Behavior-driven Development)は、 ビジネス側が書いたシナリオ(誰が、どんなとき、どの条件で、どうしする)や仕様をもとに、コンピュータで実行可能なテストを自動生成し、システム側がそのテストを通るようにシステム開発をしていく方法です。ビジネス側がBehaviorを書く際の言語は、ビジネス側でもできるだけ理解できる自然言語風の、BDD専用言語です。 BDDのメリットは、 ビジネス側の仕様記述から、システムテストを作成できるので、ビジネス側の望んでいるシステムを素早く正確につくれる ビジネス側の仕様変更がダイレクトにシステムテストに反映されるので、仕様変更にも強い ことかと思います(筆者の理解)。 筆者がBDDを支持しない理由 1番目の理由は、そもそもビジネス側の期待している振る舞い (Behavior) 自体が曖昧で、それを論理的に整合性のある仕様に落とし込むことが、システム開発で最も困難な場合が多いと感じるからです。 ビジネス側の期待している振る舞いが簡潔で、論理的であればあるほとプログラムとして記述しやすくなるはずなので、その場合は、システム側だけのTDD (Test Driven Development) 方式で開発を進められると思います。 BDDの記述方法も所詮は論理記述の一種なので、それが綺麗に書ける人はそもそも、エンジニアとしての才能があるので、普通に綺麗な仕様を書ける場合が多いのではないでしょうか。 2番目の理由はBDDの記述言語です。 自然言語風にするのはいいのですが、自然言語に近づければ近づけるほど、論理の矛盾や文法チェックが必要になり意味解釈が面倒になると思います(自然言語処理が簡単であれば、自然言語処理という研究分野は存在しないはず)。 もちろんBDDの記述言語はプログラム言語を自然言語風にしたシナリオ記述言語なので、意味解釈の面で問題が出ることはないと思います。 しかしそうすると、BDDの記述言語には表現に制約があり、最終