ISim によるテストの自動化を考えるのバックアップ差分(No.2)

更新
追加された行はこの色です。
削除された行はこの色です。
[[公開メモ]]

#contents

* テストを自動化したい [#u7f97791]

* ファイルをどのように配置するか [#yb72c04c]
** テスト駆動開発 [#za66cb5b]

ソフトウェア開発で最近はやりの手法として、
テスト駆動開発(TDD: test-driven development)というのがあります。
ISim を使って似たようなことをやりたいというのがこの記事の趣旨になります。

背景としては・・・

ソフトでも、回路でも、プロジェクトが大きくなり複雑になると、
コードの一部を修正したことが、思ってもみない部分に波及して、
新しいバグを生んでしまう（デグレードしてしまう）不幸が頻繁に起こります。

かといって、「動いているコードを変更するなんて愚の骨頂」などという
旧態依然とした態度でいると、バグつぶしや新機能の導入のたびに、
場当たり的なつぎはぎが行われ、コードの見通しが悪くなったり、
構造的なゆがみが蓄積してして、結局どこかで破綻をきたします。

そこで、コードに加えた変更がどこか他に悪影響を与えないことを
確信できるようにして、既存コードの改変を容易にしようというのが
テスト駆動開発の原点になっています。

（ソフトの方では、テストをしやすい
モジュール構成にすること自体が、結果的に見通しの良い設計を誘発するとか、
テストを書くことで仕様が明確になる、とか、他にもいろいろ利点が
あることが宣伝されていますので、興味のある方はgoogleってみて下さい。）

gui がからむソフト開発に比べ、回路は動作を機械的に定義しやすいので、
テスト駆動はとても向いてると思うんです。

** テスト駆動開発の流れ [#u89c3feb]

理想的なテスト駆動開発では、コードを書いたり、変更したりするのに先だって、
まずそのコードがクリアすべきテストを記述します。

そうやってテストを記述した後、実際のコードを書いて、
そのコードがちゃんとテストをクリアすることを確認して、
ようやく次のコードに移ります。

次のコードを書くときにはまた、先にテストを書いて、次にコードを書いて、
とやりますが、そのコードをテストする際には、はじめのテストと新しいテストの
両方が問題なく通ることを確認します。

つまり、後から書いたコードがそれ自身の目的を果たすだけでなく、
元のテストの結果を悪化させていないことも確認するわけです。

そのようにしていくと、コードが増えると同時に、テストもどんどん増えていき、
理想的にはすべてのコードがテストで守られている状況を作ることができます。

このようになっていれば、コードにどんなに大きな変更を加えても、
その後すべてのテストを走らせることで、
その変更がデグレードを引き起こしていないという確信を持てる
理想的な状況を実現できます。

この安心感があるおかげで、テスト駆動開発ではすでに動いているコード部分に
ついても、コードの読みやすさや、構造的な改善のため、一部を改変することが容易であり、
常にコードを読みやすく、直しやすい状態に保つことができます。

このようなテストに裏打ちされた既存コードの改善
（動作を変えずに読みやすさや構成を改善する変更）は
専門用語で「リファクタリング」と呼ばれています。

** テストの自動化が重要 [#ud0d3c96]

上記の説明で分かるとおり、テスト駆動開発ではコードと同じか、
あるいはそれを上回る量のテストが書かれます。

そして、コードの主要な改変のたびに何百、何千、
時には何万もあるすべてのテストを走らせる必要があります。

したがって、普通にテストベンチを書いて、その結果波形を目で追いながら確認する、
というような従来型のテストベンチの使い方は、テスト駆動開発では役に立ちません。

テスト駆動開発でのテストは、次のような自動テストであることが必須です。
+ テストはかならず「成功する」か「失敗する」かのどちらかを結果とする
+ すべてのテストを自動的に連続して走らせることができる
+ どのテストが成功して、どのテストが失敗したかを容易に把握できる

** ISim を使った自動テストに必要な技術 [#l6e21a7b]

同様の自動テストを ISim を使った Verilog 
コード検証で行いたいと思うのですが、そのためには
Xilinx WebPack 上の ISim を使って、

- 「成功」か「失敗」かを返すテストベンチの書き方
- 書きためた無数のテストベンチを一気に走らせる方法
- テストベンチの結果（成功・失敗）を一覧する方法
- そのあたりを考慮したプロジェクトフォルダ内のファイル配置

を確立する必要があります。

* どこかにまとめられてたりしません？ [#kfb7e2c8]

で、こういう内容を駆け出しの私一人で考えても前途多難なのは目に見えているのですが、
経験に裏付けされたお勧めのプラクティスとか、どこかで紹介されてないでしょうか？

どなたか知っていたら教えて下さい。

二度目に四角い車輪を発明するような愚は犯したくないのです（−−；

** 見つけられないでいます（ＴＴ [#yee8fa28]

とはいえ、自分ではこれまで上記のような内容の記事を見つけられていません。

しかたないので、以下で苦しむ過程を書きつつ、何とか良さそうな解を探ってみようと思います。

今更こんなことを調べているのはかなり不毛な気がするので、
どこかに答えがあればどなたかぜひ教えて下さい！

* 「成功」か「失敗」かを返すテストベンチの書き方 [#wdd688a8]

目視の試験を行った際に、うまく動いたことが確認できた波形を機械的に記録して、
その後は実波形と理想波形との差分を取る、といった機械的な方法もありかも？

できれば失敗位置をコード上で簡単に見つけられるようにしたい。

* 書きためた無数のテストベンチを一気に走らせる方法 [#vd7f748e]

前テストを走らせるのにある程度時間がかかってしまうのは仕方がない。

バッチファイルあるいはmakefileのような物で一気にコンパイル＆実行ができるようにしておいて、
結果だけを確認できる形にしたい。

本来なら gui 化して、必要な範囲のテストだけを走らせる、
なんてこともできればよいのだけれど、そこまでは望めない・・・かな？

* テストベンチの結果（成功・失敗）を一覧する方法 [#kd26a735]

ログファイルを grep あるいは ruby かなにかのスクリプトで
処理すればできるんじゃないかと考え中。

* プロジェクトフォルダ内のフォルダ構成をどうするのが良いか [#yb72c04c]

これ結構重要なんだけど、試行錯誤が必要になりそう。

* コメント [#h77e4c69]

#article_kcaptcha
Counter: 34028 (from 2010/06/03), today: 2, yesterday: 0