2021年10月29日 / 最終更新日時 : 2021年10月29日 user 事例・ソリューション

継続的テストを次のレベルへ

あなたは継続的テスト（CT）を実施しています。プログラマーがコードをチェックインすると、10分後にはすべての単体テストが成功していることを確認した中間レポートが送られてきます。素晴らしいですね！まれに問題が発生してもすぐに特定できます。他の問題に何時間も何日も対応しているうちに問題が埋もれてしまうことなく、はるかに少ない労力で解決できるという大きな利点があります。

それが継続的テストの本来の姿です。しかし、あなたの開発チームは気づいていないかもしれませんが、継続的テストは、組織があなたのアウトプットと認識しているプログラミング言語をはるかに超えて、広範囲に広がることがあります。

ソフトウェアをBashやPowerShell、Makeでビルドしていますか？それらのビルドスクリプトもテストが必要です。
また、データベースへのアクセスにSQLを使用していますか？自動化した検証によって、データベーススペシャリストの生産性を高めましょう。
CSSのソースに、古い仕様や廃止された技術的負債が蓄積されていませんか？自動化ツールを導入することで、そのような「汚れ」を取り除くことができます。

ユーザーとのやり取りをより厳密にモデル化するテストは、テスト技法の最も一般的な焦点であり、もちろん、そのレベルでの作業は常に最重要なものです。しかし、特定の成果物の確認を自動化することは、小規模ではありますが、多くの利点があります。いくつか例を考えてみましょう。

HTML

筋金入りの組込プログラマーであっても、定期的にコマンドラインの聖域から抜け出し、ドキュメントやダッシュボードといった HTMLベースの成果物を作成します。ほとんどの人にとって、Webアプリケーション、少なくともWebサイトは日常業務の一部です。

しかし、HTMLとその妥当性に焦点を当てることに価値はあるのでしょうか？
Webアプリケーションがすべてのテストに合格しているなら、なぜその中に入っているHTMLの構文をチェックするのでしょうか？

少なくとも3つの答えが、商業的な状況に広く当てはまります。

通常、HTMLの検証は高速なチェックです。たとえば、編集中に <ul> タグを <ui> タグにするなどのミスがあった場合、バリデーターは通常1秒以内に間違いを発見できますが、完全なテストスイートは通常数分から数時間かかります。継続的テストがエラーを発見するのが早ければ早いほど、HTMLコーダーはエラーを迅速に修正し、ソフトウェアを正常に戻すことができます。
構文が適切なHTMLは検索エンジンのランキングを上げると広く信じられています。
構文が適切なHTMLは保守性が高いです。

最後の点については、もう少し説明する必要があるでしょう。
主要なブラウザーが期待通りにレンダリングするという意味では要求を満たしているが、不完全なHTML（たとえば、終了タグがないソース）はよくあります。しかし、不完全なHTMLは壊れやすいものです。不完全な部分の近くに別の項目を追加した場合、ブラウザーによっては期待するレンダリング結果にならない場合があります。しかし、HTMLの構文が適切であり、メンテナンス時にも妥当性が保たれていれば、異なるブラウザーでも一貫して正しく表示され続ける可能性がはるかに高くなります。

HTMLの検証は良いアイディアだと思いますか？
一般的には、良いアイディアだと言えます。検証することで、より早く、より少ない労力でエラーを発見できます。確かに私は多くのプロジェクトでHTMLの検証を自動化してきました。

しかし同時に、HTMLを検証しない理由もあることに注意してください。

HTMLが非常に小さいか静的であるため、検証を自動化する価値がない。
組織が妥当性を重視しておらず、指摘事項があったとしても無視できる厄介なものとしてしか扱っていない。
テストにはもっと緊急性の高い優先事項があり、HTML以外の領域に注意を向けることを選択している。私はよくhtml5validatorを使用していますが、html5validator は CSS と SVG にも対応できます。

shell

shell (Bash、PowerShellなど) は、自動化に非常に適した領域です。たとえ数十行のshellがプロジェクトの他の部分を結合しているだけだと思っていても、それらshellに対する検証を検討するべきです。

set -euf -o pipefail などによる「安全な shell」のソース内設定
shellcheckなどの静的解析ツール
Bashスタイルガイドの研究

これらのツールは、割り当てられていない変数、ホワイトスペースのエラー、混乱した評価コンテキスト、気づきにくいスペルミスなど、他の方法では発見できないようなものを発見するのに適しています。

また、Perl、PHP、VisualBasicなど、今ではあまり使われなくなった言語の小さなコード断片も、プロジェクト間をつなぐ「接着剤」として登場します。これらの言語には、それぞれの言語固有のチェッカーがあり、ソースの品質を確保するのに役立ちます。

JSON

JSONはしばしばXMLの代替となります。JSONは通常、よりシンプルで明確です。また、経験の浅い人が記述する可能性も高く、自動化されたチェッカーは、管理の甘いJSONソースにありがちな不適切なカンマや引用符をすぐに発見してくれます。

Markdown

MarkdownはHTMLとほぼ同等のものです。Markdownは主にテキストコンテンツを伝達するフォーマットであり、HTMLと同様に、構文の多少の不完全さには寛容です。Markdownのレンダリングエンジンは構文が適切ではないMarkdownであっても、それらしい解釈をしてくれます。

HTMLと同様に、適切なスタイルのMarkdownはメンテナンスが容易です。MarkdownlintはMarkdownのソースを適切な構文に保つのに役立ちます。

また、HTMLとMarkdownの両方に共通しているのは、多くのプロジェクトがこれらの言語に依存しながら、テンプレート化されたソースを保守していることです。たとえば、Webサイトの個々のページはJinjaで記述され、これをアプリケーションサーバーがHTMLとして配信することがあります。多くの場合、「テンプレートが適切な構文で構成されていることを確認するためのテスト」と「コンテンツが適切にレンダリングされていることを確認するためのテスト」を別々に自動化することは有用です。

And more

いつものように、テスターとしてのあなたに役立つのは、ここまでで述べた一般的な説明をあなた自身の状況に適応させることです。私は、上記のチェッカーではカバーできないスタイルの詳細を確認するために、専用のチェッカーを作成してきました。また、SQL、crontab、C# など、他の多くの言語にもチェッカーが用意されています。私の経験では、チェッカーを規律正しく自動で適用することで、チェッカーがなければ発見するのに長時間かかったであろうエラーを必ず検出できます。

今ある継続的テストは単なる出発点に過ぎません。継続的テストに少しのエネルギーと創造性を加えることで、継続的テストの価値は格段に上がり、ソフトウェア製品やサービスの品質を大幅に向上させることができるのです。

作者について：

Cameron Lairdは、受賞歴のあるソフトウェア開発者であり著作者です。業界のサポート団体や標準化団体に参加しており、Python Software Foundationの投票メンバーでもあります。長年テキサス湾岸に居を構え、お気に入りのアプリケーションは農業自動化向けのアプリケーションです。

（この記事は、開発元 Ranorex 社 Blog 「Take Your Continuous Testing to the Next Level」2019年12月18日の翻訳記事です。）