.NET Framework 4 に移行した際に全パスのテストは必要なのでしょうか？

Question

お世話になります。

.NET Framework 4ではmsorlibといったコア部分のクラスライブラリやCLR自身のバージョンが上がるということですが、.NET Framework 2.0 から移行する場合は全パスのリグレッションテストが必要になるのでしょうか？

Answer 1

.NET Framework 4 に移行するということは、開発環境を Visual Studio 2010 に乗り換えると言うことですよね。
開発環境を乗り換える際に、どの程度のテストが必要かで考えてみてください。

# 確か、.NET Framework 4 を入れるだけでは、.NET Framework 4 の CLR で実行されるわけではないので、
# 乗り換えるという前提で発言しています。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 2

Azuleanさん、返信ありがとうございます。

VS2010+ターゲットフレームワーク4ということを想定しています。

将来的に.NET Framework3.5がサポート切れで、.NET Framework 4 （あるいはそれ以降）に移行しようという話になったときに、どうテストしたらよいものかと。。。

「心配なら全部テストしといた方がいいよ」くらいですかね？

Answer 3

>「心配なら全部テストしといた方がいいよ」くらいですかね？

理屈としては、「動作保証を行うすべての実行環境で全パステストをするべき」だと思います。

開発環境を VS2010 に移行するということは、まずユーザコードのコンパイル結果が異なります。
ということは、以前テストを通過したアセンブリとはこの時点で「別物」なわけで、テストをするべき理由としては十分なはずです。

おまけに、実行の中核となる CLR が別物に変わっているということは、JIT の結果も異なります。
標準ライブラリにも追加・削除（はあまりないのかな？）・修正が行われているため、以前テストを実施したのとは異なるものになっています。

Answer 4

渋木さん、返信ありがとうございます。

やはり全パステストなんですね。お客様としては見た目使い勝手が特に変わりがなくて、内部的なCLRが変わるだけなところにコストをかけるのはなかなか辛いです。まあ.NETで作っている以上は避けて通れないってことですね。

さらに質問ですが、もしコストを下げたいというのであればNUnitやMSTestで自動化をすすめるってことでしょうか？

Answer 5

>まあ.NETで作っている以上は避けて通れないってことですね。

特に .NET 限定の話ではありません。

前回も書きましたが、CLR のバージョンが上がる云々の前に、使用するコンパイラのバージョンが変われば出来上がる実行形式も別物になるわけで、それだけでも全テストを行うには十分な根拠になります。

それに加えて、アプリケーションの実行に不可欠ななサブシステムのメジャーバージョンが変わるわけですから、全テストを「省略できる」と考えるのが間違いです。

>もしコストを下げたいというのであればNUnitやMSTestで自動化をすすめるってことでしょうか？

テストの自動化はコストよりも、むしろテスト品質の向上に貢献します。

アプリケーションがリリースされるまでの間、単体テストは何度も行うことになるわけで、それを毎回手動で行っていたら人為的なミスが容易に発生します。

単体テストを自動化すれば、そういった人為的なミスを排除できます。

ただし、良質な自動テストを行うためにはそれなりのコストを投入しなければなりません。

Answer 6

外池と申します。

「.NETで作っている以上は避けて通れない」というのは、ちょっと違うように思いますが。

このスレッドでは.NETのメジャー・バージョンアップに際するテストのお話をされているようですので「開発環境が変わる」、「コンパイラのバージョンが変わる」、あるいは「実行環境のプラットフォームが変わる」というレベルの話題と同等なのではないでしょうか？

それを踏まえて、「さらに質問ですが」の部分も、もう少し検討の余地があろうかと思います。

.NET 2、3、3.5のサポートが切れて、.NET 4以降しかサポートされていない時期というのは、OSのバージョンもかなり先に行ってるように思います。その頃には「見た目」「使い勝手」は相当に変化している可能性があります。

私が「不真面目モード」のときなら「その時」になったら考えれば良いや・・・、って感じかな。

私が「真面目モード」のときなら、今のうちにGUIとGUIじゃない部分をできるだけ綺麗に分けて、GUIじゃない部分は自前のテスト環境を構築することを急ぐと思います。GUIは、どれだけ真面目になっても、たぶん「その時」しか対応できないように思います。

---

（ホームページを再開しました）

Answer 7

お客様としては見た目使い勝手が特に変わりがなくて、内部的なCLRが変わるだけなところにコストをかけるのはなかなか辛いです。

.NET Framework 3.5 のサポートが終了するまでの間に、見た目も使い勝手も機能も変わる予定がないということでしょうか？
メジャーバージョンアップのときに、開発環境も移行していければ、顧客も納得してくれそうな気はします。

# 「内部的な CLR が変わるだけ」ではなく、「OS を含めてきちんとサポートできる環境を提供する」と考えるべきなような。
# OS のサポート切れなどでも環境を更新しない場合、セキュリティリスクを高まるわけですし。

まあ.NETで作っている以上は避けて通れないってことですね。

私も、.NET Framework だからという問題ではないと思っています。
開発環境のサポート切れであるとか、Windows (OS) のサポート切れとか、ネイティブアプリケーションでも十分にあり得る話です。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 8

みなさま、回答ありがとうございました。

確かにCLRだけでなく、OSとか開発環境、ハードウェアなどいろいろな要素がありますね。

情報収集を怠らずに計画的にバージョンアップに対応しようと思います。

ありがとうございました。