Copeが教えてくれた、TDD否定派論文の紹介 その2

引き続き、Copeが教えてくれた論文の紹介です。同じ人が書いた、続きの位置づけのような論文です。

"Does Test-Driven Development Improve the Program Code? Alarming Results from a Comparative Case Study" Maria Siniaalto and Pekka Abrahamsson, Balancing Agility and Formalism in Software Engineering, 2008

内容について誤解や勘違いをしている部分もあるかもしれません。ご了承ください。

この論文も有料で読めます。著者は、前回紹介した論文と同じ2人で、前の研究の続きという位置づけのようです。

まず先行する5つの研究を紹介しています。それぞれ、TDDと非TDDの開発を比較して、メトリックスで評価したものです。

そうした研究を踏まえた上で、メトリックスとしては確立した(議論はあるものの)ものを採用しています。名前だけ紹介します(わたしはあんまりよく理解できていない)。

  • Traditional Methods
    • WMC (weighted methods per class)
    • DIT (depth of inheritance tree)
    • NOC (number of children)
    • CBO (coupling between objects)
    • RFC (response for a class)
    • LCOM (lack of cohesion in methods) ここまで Chidamber and Kemerer
    • LCOM* これは Henderson-Seller
    • 循環的複雑度 (cyclomatic complexity) McCabe
  • Dependency Management Metrics (Robert C. Martin)
    • Ca, Ce, A, I, D'

この研究では5つのプロジェクトを対象に調査をおこなっています。いずれも実ユーザーに提供するソフトウェアで、2プロジェクトはITL(テストラストのイテレーティブ開発)で、3プロジェクトはTDDです。開発期間は9週間、Mobile-Dというアジャイル手法を採用しました。メンバーは完全に均質とは言えないもの、同等の能力になっています。

結果は、traditional methodsのなかではDIT、RFC、循環的複雑度の3つについて統計的に意味ある差異が認められました。継承を測るDITは高く(悪く)、複雑度を測るRFCと循環的複雑度は小さい(良い)。

またDependency Managementメトリックスでは、Distance from the Main Sequenceという評価値でTDDのほうが大きい(悪い)結果が出ています。これはパッケージの安定度と抽象度を測定するもので、TDDのほうがパッケージ構成が悪いという数字です。ただしITLのプロジェクトではパッケージが2つだけだったのに対し、TDDでは4〜8つのパッケージだったことが数値に影響している可能性に言及しています。

結果の評価としては、DIT、RFC、循環的複雑度に差異が見られたもの、この結果は先行する研究と一致していない部分があります。DITは悪い数字が出ていますが、全体に継承はほとんど使われていないのではっきりした結論は出せないと述べています。

Dependency Managementメトリックスではパッケージ構成がTDDのほうが悪い結果が出ており、TDDのほうがメンテナンスしにくいコードを産み出すと結論づけられます。これは一般にTDDの効果と謳われているものに反しています。いっぽうそもそもパッケージ数にITLとTDDでは差がある点も考慮する必要があります。

論文の結論では、TDDが内部品質を必ずしも自動的に、はっきりと改善するとは言えないと述べています。複雑度を下げる効果も見られるが、パッケージ構成を悪くする効果も見られます。外部品質を改善する効果があるとは言えるものの、著者らは、TDDを使わずに従来型のユニットテストをおこなうだけでも同じように外部品質が改善されるのではないかと疑義を呈しています。

感想

TDDを使うだけで設計が劇的に良くなるわけではないという話は、その通りかなと思えます。いっぽう研究ではITLもTDDもそこそこいい設計ができているように思え(たとえばクラスのメソッド数はだいたい20まで、継承は最大3段階)、比較は別として、TDDでよい設計ができると言ってもよさそうに思います。

Dependency Managementメトリックスの数値を取り上げてTDDのほうが設計(パッケージ構成)が悪いというのは、かなりこじつけだと感じました。ITLではパッケージ数が2のため、メトリックスの特性上(パッケージ内のクラスと外のクラスの依存が多いほど数字が悪くなる)、単純に比較できないのではないでしょうか。TDDではパッケージ数が4〜8というのは、パッケージ構成を意識している現れであり、むしろ良いことのように感じます。

この研究ではメトリックスを使って複数のプロジェクトを比較しているのですが、どこまで有効なのか疑問を感じました。開発の進め方や内容やメンバーを揃えて、対照できる状態にしていると論文では主張していますが、ITLならITL、TDDならTDDで同じような数字になっているかというと、グラフを眺める限り必ずしもそうは見えません。プロジェクトの規模が小さい(5000〜7700LOC)からも、結果の有効性を疑いたくなります。

同一のプロジェクトの中で、TDDを利用しているときとしていないときの比較ならば、メトリックスで明確に把握できると思うので、そういう研究があるといいなあ。