トップ回答者
.NET Framework 4 に移行した際に全パスのテストは必要なのでしょうか?

質問
回答
-
>まあ.NETで作っている以上は避けて通れないってことですね。
特に .NET 限定の話ではありません。
前回も書きましたが、CLR のバージョンが上がる云々の前に、使用するコンパイラのバージョンが変われば出来上がる実行形式も別物になるわけで、それだけでも全テストを行うには十分な根拠になります。
それに加えて、アプリケーションの実行に不可欠ななサブシステムのメジャーバージョンが変わるわけですから、全テストを「省略できる」と考えるのが間違いです。
>もしコストを下げたいというのであればNUnitやMSTestで自動化をすすめるってことでしょうか?
テストの自動化はコストよりも、むしろテスト品質の向上に貢献します。
アプリケーションがリリースされるまでの間、単体テストは何度も行うことになるわけで、それを毎回手動で行っていたら人為的なミスが容易に発生します。
単体テストを自動化すれば、そういった人為的なミスを排除できます。
ただし、良質な自動テストを行うためにはそれなりのコストを投入しなければなりません。- 回答としてマーク koty 2010年2月22日 0:26
-
外池と申します。
「.NETで作っている以上は避けて通れない」というのは、ちょっと違うように思いますが。
このスレッドでは.NETのメジャー・バージョンアップに際するテストのお話をされているようですので「開発環境が変わる」、「コンパイラのバージョンが変わる」、あるいは「実行環境のプラットフォームが変わる」というレベルの話題と同等なのではないでしょうか?
それを踏まえて、「さらに質問ですが」の部分も、もう少し検討の余地があろうかと思います。
.NET 2、3、3.5のサポートが切れて、.NET 4以降しかサポートされていない時期というのは、OSのバージョンもかなり先に行ってるように思います。その頃には「見た目」「使い勝手」は相当に変化している可能性があります。
私が「不真面目モード」のときなら「その時」になったら考えれば良いや・・・、って感じかな。
私が「真面目モード」のときなら、今のうちにGUIとGUIじゃない部分をできるだけ綺麗に分けて、GUIじゃない部分は自前のテスト環境を構築することを急ぐと思います。GUIは、どれだけ真面目になっても、たぶん「その時」しか対応できないように思います。
(ホームページを再開しました)- 回答としてマーク koty 2010年2月22日 0:26
-
お客様としては見た目使い勝手が特に変わりがなくて、内部的なCLRが変わるだけなところにコストをかけるのはなかなか辛いです。
.NET Framework 3.5 のサポートが終了するまでの間に、見た目も使い勝手も機能も変わる予定がないということでしょうか?
メジャーバージョンアップのときに、開発環境も移行していければ、顧客も納得してくれそうな気はします。
# 「内部的な CLR が変わるだけ」ではなく、「OS を含めてきちんとサポートできる環境を提供する」と考えるべきなような。
# OS のサポート切れなどでも環境を更新しない場合、セキュリティリスクを高まるわけですし。
まあ.NETで作っている以上は避けて通れないってことですね。
私も、.NET Framework だからという問題ではないと思っています。
開発環境のサポート切れであるとか、Windows (OS) のサポート切れとか、ネイティブアプリケーションでも十分にあり得る話です。
質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。- 回答としてマーク koty 2010年2月22日 0:25
すべての返信
-
.NET Framework 4 に移行するということは、開発環境を Visual Studio 2010 に乗り換えると言うことですよね。
開発環境を乗り換える際に、どの程度のテストが必要かで考えてみてください。
# 確か、.NET Framework 4 を入れるだけでは、.NET Framework 4 の CLR で実行されるわけではないので、
# 乗り換えるという前提で発言しています。
質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。 -
>「心配なら全部テストしといた方がいいよ」くらいですかね?
理屈としては、「動作保証を行うすべての実行環境で全パステストをするべき」だと思います。
開発環境を VS2010 に移行するということは、まずユーザコードのコンパイル結果が異なります。
ということは、以前テストを通過したアセンブリとはこの時点で「別物」なわけで、テストをするべき理由としては十分なはずです。
おまけに、実行の中核となる CLR が別物に変わっているということは、JIT の結果も異なります。
標準ライブラリにも追加・削除(はあまりないのかな?)・修正が行われているため、以前テストを実施したのとは異なるものになっています。 -
>まあ.NETで作っている以上は避けて通れないってことですね。
特に .NET 限定の話ではありません。
前回も書きましたが、CLR のバージョンが上がる云々の前に、使用するコンパイラのバージョンが変われば出来上がる実行形式も別物になるわけで、それだけでも全テストを行うには十分な根拠になります。
それに加えて、アプリケーションの実行に不可欠ななサブシステムのメジャーバージョンが変わるわけですから、全テストを「省略できる」と考えるのが間違いです。
>もしコストを下げたいというのであればNUnitやMSTestで自動化をすすめるってことでしょうか?
テストの自動化はコストよりも、むしろテスト品質の向上に貢献します。
アプリケーションがリリースされるまでの間、単体テストは何度も行うことになるわけで、それを毎回手動で行っていたら人為的なミスが容易に発生します。
単体テストを自動化すれば、そういった人為的なミスを排除できます。
ただし、良質な自動テストを行うためにはそれなりのコストを投入しなければなりません。- 回答としてマーク koty 2010年2月22日 0:26
-
外池と申します。
「.NETで作っている以上は避けて通れない」というのは、ちょっと違うように思いますが。
このスレッドでは.NETのメジャー・バージョンアップに際するテストのお話をされているようですので「開発環境が変わる」、「コンパイラのバージョンが変わる」、あるいは「実行環境のプラットフォームが変わる」というレベルの話題と同等なのではないでしょうか?
それを踏まえて、「さらに質問ですが」の部分も、もう少し検討の余地があろうかと思います。
.NET 2、3、3.5のサポートが切れて、.NET 4以降しかサポートされていない時期というのは、OSのバージョンもかなり先に行ってるように思います。その頃には「見た目」「使い勝手」は相当に変化している可能性があります。
私が「不真面目モード」のときなら「その時」になったら考えれば良いや・・・、って感じかな。
私が「真面目モード」のときなら、今のうちにGUIとGUIじゃない部分をできるだけ綺麗に分けて、GUIじゃない部分は自前のテスト環境を構築することを急ぐと思います。GUIは、どれだけ真面目になっても、たぶん「その時」しか対応できないように思います。
(ホームページを再開しました)- 回答としてマーク koty 2010年2月22日 0:26
-
お客様としては見た目使い勝手が特に変わりがなくて、内部的なCLRが変わるだけなところにコストをかけるのはなかなか辛いです。
.NET Framework 3.5 のサポートが終了するまでの間に、見た目も使い勝手も機能も変わる予定がないということでしょうか?
メジャーバージョンアップのときに、開発環境も移行していければ、顧客も納得してくれそうな気はします。
# 「内部的な CLR が変わるだけ」ではなく、「OS を含めてきちんとサポートできる環境を提供する」と考えるべきなような。
# OS のサポート切れなどでも環境を更新しない場合、セキュリティリスクを高まるわけですし。
まあ.NETで作っている以上は避けて通れないってことですね。
私も、.NET Framework だからという問題ではないと思っています。
開発環境のサポート切れであるとか、Windows (OS) のサポート切れとか、ネイティブアプリケーションでも十分にあり得る話です。
質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。- 回答としてマーク koty 2010年2月22日 0:25