Home Blogs テスト主導の開発にはQA以上のものがあります。
Applications

テスト主導の開発にはQA以上のものがあります。

About The Author

Outline

ソフトウェアの世界では、ほとんどではないにしても、テスト駆動開発(TDD)を、狭義にはソフトウェア開発特有のプロセスと考えるようになってきまし た。 多くの議論や議論は、所定のコードベースが説明どおりに機能することを実証する目的で、事前定義された要件のリストに対してコードの隅々まで実行するように設計された特定のツールやテクニックの使用を中心に行われてきた。 あまりにも頻繁に起こるように、信号をノイズから分離したり、原理を実践から分離したりすることが困難になり、実装の詳細に迷い、元の意図を見失ってしまいます。 そこで、一歩下がって、テスト主導型開発に関する会話を再考しましょう。具体的には、それは何ですか、そしてそれはあなたのビジネスにどのように役立つのでしょうか?

TDDとは

ビジネスの文脈では、ソフトウェアの目的はそのビジネスに価値を付加することです。 このため、開発作業における重要な課題の1つは、ビジネス要件と目標を対応するシステム要件にマッピングすることです。 この後、問題は次のようになります。これらの要件を満たすソフトウェアをどのように作成し、プロジェクトとそのコードベースが拡大するにつれて、ソフトウェアがこれらの要件を引き続き満たしていることを確認するにはどうすればよいですか。

「テスト主導型開発」を開始します。

テスト駆動開発(TDD)は、ソフトウェアを記述して実行するテストを書くことによってソフトウェアを作成するための組織的な方法論です。 TDDの中核は、失敗したテストを書く、合格する、リファクタリングするという3つのステップを繰り返すことです。

ここでの概念は、開発中のソフトウェア機能の一部を記述するテストから開始することです。 テスト対象のコードがまだ書かれていないため、このテストを初めて実行すると失敗します。 当然のことながら、次のステップは、元のテストパスを作成することを目的として、機能の実装に取り組むことです。 3番目の、そしておそらく最も重要なライフサイクルのステップは、コードをリファクタリングすることです。

ソフトウェアを書くことは、その本質的な品質だけでなく、その動的な性質のためにも挑戦しています。 ビジネス要件は常に変化する可能性があり、その結果、ソフトウェア要件に適応できる必要があります。 今日書かれたコードは今日のニーズに合っていますが、明日、または明日から1か月後に何かが変化し、その結果、今日のコードは特定の問題を解決する最良の方法ではなくなる可能性があります。 ソフトウェアと比較する仕組みを導入することで ソフトウェアが何を記録しているのか すべき 実行するすべてのテストに合格している限り、システムの出力は同じであると確信できるため、コードを大胆に引き裂く、書き直す、その他の方法で今日の要件を満たすためにコードを再配線することができる強力なツールができました。

TDDを使用する理由

ヘルシンキ大学による2014年のレビューでは 、多くの場合、TDDは欠陥、品質、複雑さ、保守性の面でプラスの効果をもたらしているが、これらの改善は開発努力の増加を犠牲にしていることが判明した。 追加テストを書くには追加の努力が必要であることを考えると、これは驚くべき結論ではありません。しかし、この性質の研究で除外されているのは、フィードバックであるTDDの主な利点です

フィードバックループを閉じることは、変更を加えて何かを学ぶのにかかる時間を短縮することを意味します。 これを迅速に行うことができれば、俊敏性が高まり ます。 開発の生産性を定量化しようとするほとんどの指標は、時間の経過に伴う作業単位に関連しており、実用的なフィードバックを受け取るのにかかる時間を短縮することで、TDDは貴重なリソースをより効率的に使用することができます。 時間は金であると言われているので、ここでの経済的利益は自明です。 ソフトウェア開発ライフサイクルの中で「左シフト」について誰かが言及するのを聞いたことがあるなら、これはまさに彼らが言及していることです。

アプリケーション用のテストスイートを持つことのもう1つの利点は、テストスイートを自動化できることです。 開発者はこれらのテストを開発ライフサイクルの一部として実行できるだけでなく、スモークテストやCI/CDパイプラインの一部として他のシステムで実行でき ます。 コードを市場に配信する手順を自動化することで、製品全体をより迅速に配信できるようになり、ユーザーからのフィードバックを迅速に受け取り、そのフィードバックを解釈して次のイテレーションに適用できます。

これら2つの点の相乗効果は明らかです。 開発者がビジネスニーズに合わせてコードベースを継続的に適応させることができるコードベースと、ビジネスが顧客から迅速にフィードバックを求めることができる機能により、チームが少ない作業でより多くの価値を提供できるシステムが実現します。

TDDを最大限に活用する

テスト駆動開発は、ソフトウェアのテストに対するさまざまなアプローチの1つにすぎません。 どのように実装しても、重要なのは、組織に価値を提供することです。 他の分野と同様に、組織のニーズに完全に基づいて、自由に使用したり、適切に適応したり、まったく使用しないようにしてください。 そうは言っても、預言者クラプトンが予言したように、あなたがTDDの道を歩くことを選択したならば、「それはあなたがそれを使う方法の中にあります」。

他のツールと同様に、TDDの有効性と価値はその実装に依存します。 ソフトウェア開発では、プロジェクトの失敗や欠点を説明するために、さまざまなツールやテクニックがスケープゴートに変換されますが、ツールを非難するのは貧しい職人です。 それでは、TDDを最大限に活用する方法に焦点を当てましょう。

文化リファクタリング

TDDの最後の最も重要なステップ はコードをリファクタリングすることですが、TDDが機能するためには、リファクタリングを行うだけではない可能性があります。 何らかの形でテスト駆動型開発を実施することを選択した場合、周囲の文化もこのスタイルの開発哲学をサポートするように適応することが重要です。

TDDの場合、最も一般的な失敗は、テストを書いて合格し、リファクタリングが実際に完了することはなく、リファクタリングのステップをスキップすることによって短絡されることです。 多くの場合、問題はTDDやその他の特定の技術ではなく、ソフトウェアが開発されている文化そのものです。

ドキュメントとは異なり、リファクタリングは、締め切りや予算が制約されたときに最初に放り出されるものの1つのようです。結局のところ、誰かがこれらのテストをすべて書かなければならないから です。 したがって、クランチの間に、テストやドキュメント、およびミッションクリティカルではないと考えられるその他のものはすべて放棄されます。 コードベースの全体的な品質が着実に低下し、代わりに技術的負債が蓄積されていく。

リファクタリングは、単純に機能するコードを、よりクリーンでメンテナンス性の高いコードベースに変換するプロセスのステップです。 開発者が一歩下がってシステム全体のパターンを認識し、より汎用性の高い方法に適応する方法や、新たなアンチパターンを認識してそれらを軽減するための措置を講じる方法について、より多くの情報に基づいた意思決定を行うことができるようにする部分です。 アーキテクチャ全体を個別のマイクロサービスに分割する時期を認識するか、または無数の改善の可能性を認識するかの違いである可能性もあります。 このステップがなければ、イントロスペクションや漸進的な改善の機会を逃すことができ、最終的にはコードベースが徐々に(またはそうでない)大きな泥の塊へと変化するリスクがあります

テスト駆動型開発のメリットを享受するには、プロセス全体とその可能性を長期的に見て、適切な部分だけでなく、完全な「赤、緑、リファクタリング」サイクルを適用することに時間を費やすことが重要です。

Shiny New Toys

システム全体の設計に関しては、実際にコードを書かずにシステムの詳細を計画するのに多くの時間が費やされていることがよくあります。 「グリーンフィールド」プロジェクトは、クリーンな紙に関連するすべての予測可能性を備えたエキサイティングなプロジェクトです。 エンジニアも建築家も同じように「月の香り」の技術を使うことを主張していますが、何か新しいものやクールなものを試す機会を求めて、このプロジェクトに適していない可能性があるという警告サインを無視しています。 数か月後、フレームワークデュジュールはもはやチームのニーズを満たしておらず、コードの品質が低下しています。そして、プロジェクトの悪い結果のためのスケープゴートにテクノロジーがなる部分に戻ってきました。

結局のところ、重要なのは、TDDを促進するために使用されるテクノロジー、方法論、またはフレームワークがチームとビジネスのために機能することです。 あなたがあなたのツールに悩まされているならば、彼らは価値を追加しないだけでなく 、積極的にあなたに反対しています。 使用するフレームワークを徹底的に評価することに注意し、時間をかけてどのように使用するかを正確に理解してください。 このアプローチは、TDDに関連するものだけでなく、すべての設計決定に当てはまります。

まとめ

一言で言えば、TDDのようなもののアイデアは、コードベースにバグが現れないようにするための単なる技術ではなく、より適切な方法でフィードバックを収集するためのフレームワークを提供することです。 どちらのアプローチを選択しても、ビジネスとソフトウェアが変化するトレンドとビジネスニーズに迅速に適応できるようにすることが重要です。 その過程で、TDDとその対応策は、開発チームに実装を依頼して忘れるだけのものではないことに注意してください。 そして、これらの技術を効果的に活用するには、フレームワークやツールなどの実装の詳細に飛び込む前に、文化レベルでアプローチを受け入れ、有効にするように注意する必要があります。