久々の更新​

仕事にかまけてまったく更新しなくなってしまった。

GPU の入替​

2022-02 に CPU などの入れ替えをしたときは、 まだまだ高値だった GPU を見送っていた。
そんな中、2022年は画像生成系 AI が流行りに流行って、試しに動かしてみたが
GTX950 の持つ 2G メモリではとてもじゃないが生成に時間がかかりすぎて遊べない。

「GPU 高いし、また数年後に CPU とか一式入れ替えのときにまとめて交換かなぁ」と思っていたが、
GPU の価格が結構下がってきていることを観測し、「このくらいなら買っちゃうか」と衝動買い。

画像生成に使えるスペックで10万円以内、みたいな探し方をしていて、5年くらいは使えてほしいな...という希望を持って RTX4070 をチョイス。
2023-06 の購入時は 90,889円だったが、1か月経過して価格はさらに下がっていたので、しばらく待っていても良かったかも。
まぁ欲しいと思った時が買い時だと信じているので、良いタイミングだったと思う。

GPU 取付​

GTX950 の電源は6ピン、 RTX4070 は8ピンなので、大丈夫かな...？と事前に確認。

8ピンの空きがあったので一安心。
電源ユニットは750Wまでいけるので、RTX4070の動作にも耐えられそうではある。
しかし、これまで1回も交換してないな、そろそろ故障しておかしくないな。

実際に届いてから入れ替えするのは非常に簡単で、入れ替え後の作業はドライバの最新化くらいだった。
なんとなく Game Ready → Studio に変更。

画像生成​

サクサクと生成ができるようになった。
ベンチマークなどはやってないが、手持ちのゲームも4K最高画質にしてストレスなく動作することを確認。

NVIDIA Broadcast

中古パーツの買取について​

入れ替えによって使わなくなったパーツを今回もじゃんぱらに持って行ってみた。
箱が無かったのでマイナス200円。

PC 入れ替えの続き​

ハードウェアの準備は一通り完了して、マザーボードの UEFI 設定画面を起動することができた。 デフォルトだと派手に光を放っていたので、スッと無効化しておく。

CPU、Memory、GPUが問題なく認識されていることを確認したり、冷却ファンの回転数を調整して遊んでみたりした後、 さて、ブートシーケンスの順序でも設定するか、とそれらしい画面に切り替えてみたが、ブート可能な HDD が1つも無い。

あれ？ M.2 の取付ソケット間違えたかな？ SATA も3つとも接続ミスしてるとかあるのか？と思い、
再起動して F11 キーを連打するも「ブート可能なデバイスがありません」となる。

まあいいか・・・Windows 10 のインストールメディア(USB)入れて起動すればディスクが見えるかどうか分かるはず
・・・しかし、このインストールメディアすら認識されない。

ここから UEFI の設定値を1つづつチェックする作業が始まった。。。

何が問題だったのか​

結論から言うと、Windows 10 のインストールメディア(USB)を使っていると UEFI では認識されない。

【OSインストール】Windows10のUSBメモリーはUEFIブートできないため作り直す必要あり

このブログに書いてある通りで、 Rufus を使って USB メモリーに Windows 10 の ISO データを書き込むことで UEFI ブートができるようになった。
(今まで特に必要がなく、 USB メモリ※リムーバブルディスク を持っていなかったので 32GB で 1,000円くらいの製品を購入した)

試行錯誤​

ここに行きつくまでに、セキュアブートを無効化したり、レガシー起動オプションを有効化したりと迷走してしまった。
まさかメーカー純正のインストールメディアがレガシーなインストール方法にしか対応していないとは考えも及ばず、
「このメディアを使って何か設定を変えれば UEFI ブート対応できるはず」というところで思考していたので、無駄に MBR インストールしてしまい 後から UEFI メディアでクリーンインストールをする羽目になった。

MBR disk から GPT disk への変換​

MBR disk は UEFI から認識されない。
せっかく UEFI ブート可能な USB メモリで Windows 10 インストーラ を起動しても、 MBR のディスクが見えることは無い。

そこで、リファレンスを参考に インストーラのディスク選択画面でコマンドプロンプトを起動(キーボードの「Shift」と「F10」を押下)し、 diskpart を使って GPT disk に変換する
(日本語ページだと コマンドの表記がおかしいので注意)

GPT disk に変換した後は、 UEFI のブート選択画面からも参照できるようになった！

このタイミングで、レガシー起動オプションは無効化してセキュアブートを有効化した。

Windows 11 のインストール​

Windows 10 のインストールが成功し、セキュリティアップデートもすべて適用した状態で Windows 11 のアップデートツールを実行した。
M.2 の書き込みが高速なお陰で、ほとんど時間もかからず無事にアップデートが完了。 足掛け4日かけて新しい OS の UI を目にすることができた。

アプリケーションのインストール​

winget がかなり使いやすくなっていて、 Windows 11 だと標準でインストールされていた。 パッケージ名を指定して install するスクリプトを用意しておくだけで、ほとんど自動的に必要なツールのインストールが終わってしまった。

設定を復元するスクリプトも作っておくともっと楽ができそうだが、バージョンの差異によって微妙に挙動が違ったりするので このあたりは動作確認も兼ねて手動操作で見ていく感じでも良いかも知れない。

終わり​

PC 入れ替えも完了して、なにもかもがサクサク動作しており、Windows 11 使い倒してみようという気持ちになっている。

今のところ Windows 10 で動作していて 11 では動かないというものは一つもない。
UI は好き嫌いあると思うが、角丸のウィンドウデザインはしばらく使っていたら慣れてしまった。

エクスプローラのコンテキストメニューは、分かりやすさを追及して現状の形になったと思われるが、 かなりの頻度で「Show more options」を選んで旧来のコンテキストメニューを表示している気がする。
日常的な操作性は少しづつカスタマイズしていこうと思う。

せっかくだから近いうちに WinUI 3 にも入門してみようかな。

自宅のPC変遷​

自宅の私用 PC は自作するようにしている。 最初は BTO で購入したものを、部分的にパーツを交換しながら使い続けている感じだ。 最初に購入したのは2010年末、ドスパラの Prime Galleria XT というシリーズで約10万円という安めのもの。 当時は MMORPG にハマっていたので、遊んでいるゲームがそこそこ動く程度のスペックを選んだ。

構成は以下のようなものだった。

2016年頃までこのマシンを使っていたが、次第に動作の遅延を顕著に感じ始め、 Windows 10 がサクサク動くくらいのスペックの PC が欲しくなってきた。
最初の候補は新しい BTO PC を購入することだったが、想定よりも結構値段が高い。
同グレードのPCが2010年頃と比べて1.5倍くらいの価格になっている。

パーツ交換くらいは仕事でも散々やっていたので、
「必要なパーツだけ入れ替えれば安く済むのでは？」と思い、必要なパーツのみ最新化することにした。

この時購入したパーツは以下のとおり。

CPU クーラーはしっかりしたのがいいぞ、という記事を見かけて購入したけれど、 CPU にも付属のクーラーがあったのでそこまでハードに使うことも無かったしいらなかったかも知れない。 虎徹もそんなに高くないので、ちょうど良い勉強になった。

これとは別に、フロントの3.5インチベイが空いていたので OWL-CR6U3(B)/BOX という SDXC とかが使えるマルチカードリーダライタを購入した。

パーツ同士が非互換になることもなく、入れ替えは順調に行うことができた。

交換して不要になったパーツは、ドスパラの買取サービスに持ち込んで買い取ってもらうことができた。 記憶が曖昧なところだが、確か買取額が合計5,000円以上になって意外に高額になったと嬉しかった覚えがある。

パーツ交換によって Windows 10 もサクサクと起動・動作するようになった。 この経験から「自宅の PC は、故障する前に5年毎で必要なパーツを入れ替えると良い」という考えになっていった。

2022年、そろそろ Windows 11 を試したい​

2016年から早くも5年が経過した。今は2022年。Windows OS の新しいバージョンもリリースされており、 無償アップデート期間中である。

Windows 10 を動かすには 2016年に組み上げた PC でも十分だったが、 Windows 11 では Intel 6th Gen の CPU をサポートしていない。

LGA1151 でもインストールできないことは無さそうだが、このまま無理に使い続けても価値が下がる一方で いつ故障してもおかしくない期間に入っていくことになる。 BTO PC を新規購入しようとすると、希望するスペックだと予算10万円を超えてしまう。

Microsoft に踊らされている感もなくはないが、この機会に再度パーツを新調することにした。

CPU は LGA1700​

幸いにも 2021年10月頃に LGA1700 が発売されており、関連製品も充実してきている時期なので 最新の 12th Gen CPU を購入することにした。 Core i9 はハイスペックで魅力的だが、YAuth を通せる気がしないので Core i5 で十分だと思い込むことにした。

CPU のソケットにマザーボードを合わせる必要があることは前回の経験から知っていたので、 LGA1700 対応のマザーボードを ASRock の手頃な価格帯のものから選んだ。

Storage は M.2​

幸いにも HDD は故障せず、今でもドスパラの BTO マシンに取り付けられていたものが元気に稼働しているが、 SSD の速さを知ってしまったので、1TB の SSD を購入して OS の再インストールをしたりしていた。 (確か2020年頃だったと思う)

一方、SSD よりもかなり高速な Storage が存在していて、購入予定のマザーボードではヒートシンクも付属している ということで、俄然興味が湧いてきた。 Windows 11 のアップグレード前に OS は再インストールしたかったので、M.2 Storage を新たに購入して これまでに利用してきた HDD/SSD はデータディスクとして活用することにした。

互換性のあるパーツは再利用​

メモリ、GPU をどうしようか散々悩んだ。

開発中は IDE と Hyper-V や WSL2 を同時に利用するのでメモリは 16GB だと心許なく、 Storage と近いタイミングで、CORSAIR DDR4 8GB×2枚 を追加購入している。 このときデュアルチャネルのことをあまり理解しておらず、8GB×4枚と16GB×2枚だと動作速度が異なることを分かっていなかった。 32GB分の容量があるので、互換性があるメモリはそのまま使うことにした。

GPU に関しては、そもそもハイスペックを要求するようなゲームをやらないことと、マイニングなんかもやってないし 最新のパーツを新調しても変化を感じられないだろうなという結論に至った。 価格も高騰していて CPU を超えていたためなおさら足が遠のき、GPU 替えるよりかは Core i9 が欲しいという気持ちになった。 GPU も互換性がありそうだったので、購入せずに使い続けることにした。

購入したパーツ​

結果的にここまでに購入したパーツは以下となった。 CPU が4万円、MB と HDD を合わせて5万円弱という結果で予算(10万円)内に収めることに成功した。

想定外のできごと​

マザーボードからケーブルを取り外せない問題​

USB 3.0 のコネクタをどうやっても外すことができない。。。 価格.comのクチコミにもコメントがあったが、

PINは無事みたいなので、そのまま抜いてみては如何でしょうか？ USB2.0で同様にプラスチック部分がすっぽ抜けた事がありましたっけね。

という言葉通り、マザーボード側に付いていたプラスチックの端子ごと取り外してしまって、 後から端子だけ取り付けなおすみたいなことをやった。

マルチカードリーダライタはほとんど使っていないので、新しいマザーボードでは結線しないでおくことにした。

CPU クーラーが取り付けられない​

自作慣れしている人には常識だと思うが、CPU ソケットの変化によってクーラーが取付できなくなることがある。 (取付用マウントパーツが販売されていたりする)

LGA1151 → LGA1700 でも同様で、既存の CPU クーラーはまだまだ使えそうだったので転用する予定だったが、 持っているクーラーが古すぎてマウントパーツが適合しなかった。

加えて、12600K の CPU を購入していたので Intel の CPU クーラーは付属していなかった。 どうしようもなく、下記製品を追加購入することに(約5千円)

まだかろうじて予算内だ。。。

パーツ入替​

自作といいながら、やっていることは部品を入れ替えているだけなので特筆することは何もない。 私のような不慣れな人向けにメモを残すとするなら、作業の順番に気をつけると狭いところに手を入れずに済み、楽に早くできると思う。

1. 現状を写真に取りながら、マザーボードから配線を1つづつ外していく
2. マザーボードに取り付けられているパーツを全部外す

• これも写真を撮っておくと安心

3. マザーボードをケースから取り外す

• LGA1151 用のマウントパーツも一緒に除去する

4. LGA1700 対応のマザーボードにマウントパーツを取り付ける
5. マザーボードを取り付ける
6. ケースの配線をする
7. CPU クーラーを取り付ける
8. 写真を見ながら残りのパーツをすべて取り付ける

続く​

CPU クーラーの購入忘れはあったものの、パーツの取付自体はすんなり完了した。 UEFI の起動まではできたが、ブート可能な HDD が1つも無い。

UEFI とセキュアブートの知識が足りなさ過ぎたので、ここから Windows 11 のインストール完了まではまだまだ時間を要することになる。 続きはまだ後日。

追記​

中古パーツの買取について​

入れ替えによって使わなくなった下記パーツを中古パーツ買取を営んでいるじゃんぱらに持って行ってみた。
MB は箱が無かったのでマイナス400円だったが、合計8,300円になってひとまず満足。

5年毎に買い替えをすることを考えて、途中で修理に出す可能性もあるし、高額パーツの外箱は一応保管しておくことにする。

Jest v27 にアップデートすると、 Jest 実行時にエラーが出る​

Snowpack の Issue #3398 で報告されている通り、
React 向け Jest config 内で参照している Jest バージョンが古いため、実行時エラーになってしまう

● Test suite failed to run
TypeError: Cannot destructure property 'config' of 'cacheKeyOptions' as it is undefined.
  at Object.getCacheKey (node_modules/babel-jest/build/index.js:217:14)

私が確認した環境では全てのテストで上記のエラーが出ていた

原因​

• npm で配信されている Snowpack の最新版は v3.8.8(2022-01-22現在)
• Jest 利用時の config として推奨されている @snowpack/app-scripts-react は v2.0.1 が最新で、
  最終リリースは2021-03頃
• 同一リポジトリで管理されている@snowpack/app-scripts-reactは v2.0.1 時点だと babel-jest v26.2.2 を参照している
• その後、f77639bのコミットで Jest v27 対応が行われているが、リリースが行われておらず npm が更新されない

暫定対応​

問題のパッケージをアンインストール​

• @snowpack/app-scripts-react をアンインストール
• Jest の config ファイルから require を削除して、transform など必要な箇所のみコピー
  • babelTransform.js fileTransform.js importMetaBabelPlugin.js の3ファイルをコピーした

必要なパッケージを個別にインストール​

下記のパッケージが不足した状態になるので追加インストールする

• babel-jest
• babel-preset-react-app
• @snowpack/plugin-dotenv

Jest v27 にアップデートする​

• @types/jest も合わせて v27 にアップデートする

動作確認​

テストが成功することを確認する

npm run test

yarn test

Snowpack はもう開発してない？​

2021年10月以降リリースも無く、コードもほとんど動いていない

今どんな状態なんだろうか・・・
CRAv5 + Vite が安定して動いているので鞍替えしようかな

残り少ない人生、日記代わりにやったことを書き残していこうと思う

Docusaurus blogging features are powered by the blog plugin.

WPF が .NET Core 3 で動くようになりましたね。
サンプルコードを動かそうとして少しハマったのでメモを残します。

サンプルコードの取得​

https://github.com/Microsoft/wpf-samples 本家のWPFのサンプルを拝借。

それぞれのプロジェクトにおいて、 *.netcore.csproj という名前で .NET Core 向けのプロジェクトファイルが定義されていますが、 このままではビルド時にエラーが発生して動作しません。

手っ取り早く動くようにするには、以下の通り3つの作業を行います。 一時的な対応で非常に乱暴なものなので、製品として広く提供するものを開発される方はご注意ください。

実施すること​

1. .NET Framework 用のプロジェクトファイルを削除​

*.netcore.csproj を残して、ほかのプロジェクトファイルは削除してしまいます。

2. プロジェクトファイルの書換​

ビルドを実行すると、以下のようなエラーが出ます。

error MC1003: Project file cannot specify more than one ApplicationDefinition element. 
error BG1003: The project file contains a property value that is not valid. 

どうも余分な定義があるのが原因のようなので、必要最低限の定義に変更します。

<!-- 元々の内容は全て削除して以下だけにする -->
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
</Project>

3. AssemblyInfo ファイルの削除​

*Attribute 属性が重複しています というエラーが６件くらい出ていましたので、 Properties/AssemblyInfo.cs ファイル自体をごっそり消してしまいます。

結果​

あとは dotnet run するだけで起動するはずです。

記事の目的​

Visual Studio には3つのエディションがあり、価格と機能が異なります。
この記事では、各エディションの特徴を整理して、自分の目的に合ったエディションを選択できるようにすることを目的とします。

無償版(Community)ではできないこと​

一般的な企業(営利団体従事者)で5名を超える開発者がいる場合、Community は使用できないことになっており、
Professional か Enterprise を使用する必要があります。

(注) 大学関係者、非営利団体従事者、オープン ソース開発者は人数の制限なく、
また、中小企業 (PC 台数 250 台未満かつ年商 1 億円未満) においては、最大 5 名までご利用いただけます。
詳しくは Visual Studio ライセンス ホワイト ペーパーをご確認ください。

Professional でできること​

Community 版と機能的にはほとんど同じです。

CodeLens​

コードレンズは、ソースコードを解析して、クラスやプロパティ、メソッドなどの被参照箇所の情報と変更履歴情報が表示される機能です。
「自分の作るアプリケーションは、規模も小さいしそもそも一人でやっている」という方は一見必要のない機能に見えるのですが、
例えば「このメソッドに修正を加えると、どこに影響するか？」といったケースで影響箇所を調査するとき、参照箇所が数値で表示されているメリットは大きいです。

参照数が多ければ、変更したときの確認項目も増える傾向にあるため、実際の開発においては、工数見積の指標(根拠)としても使えます。

変更履歴情報については、履歴管理システムと連動して 不具合が発生した時等に何の修正によって事象が発生しているのか、追跡が容易になります。
また、リリース後にメソッドレベルであまりにも頻繁に変更が行われている場合は何らかの設計不備が疑われるため、見直しを行う契機にもなります。

Enterprise でできること​

Enterprise は、開発を効率的に進めるための強力な機能を使用できます。
Professional と Enterprise にはどちらも評価版が存在し、最大で90日間のお試し利用が可能です。

ライブ依存関係検証​

定義済みの依存関係に違反したコードを書くと、エラーにしてくれる機能です。
抽象クラスやインターフェースが具象クラスの実装仕様に依存していたり、アセンブリ間の参照関係を崩してしまうような場合に警告を出します。

コードのアーキテクチャを理解したメンバーであれば、そもそも不要な依存関係を生まないよう注意してコードを書いているものですが、
他のメンバーが常にそこまで気を付けて書いてくれる保証はどこにもありません。

この機能を使うと、コードレビュー前のコンパイル時点で依存関係を乱すコードを見つけることが可能になります。

https://msdn.microsoft.com/ja-jp/library/dd409453.aspx

アーキテクチャ レイヤー図​

レイヤー ダイアグラムを作成することができます。

https://msdn.microsoft.com/ja-jp/library/dd465141.aspx

アーキテクチャの検証​

あまり詳しい説明が見当たらない、、、
下記の説明をご参照ください。
https://msdn.microsoft.com/ja-jp/library/hh871439.aspx

コード クローン​

ソースコード量が増えてくると、似たようなコードを量産してしまい修正時のメンテナンスコストが増加するケースがあります。
コード クローンは2012から追加された機能で、コードが重複している箇所を見つけ出します。

重複箇所を抽象化して分離できれば、規模が大きくなってもメンテナンスしやすいコードを維持できます。

https://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview-JPN/Visual-Studio-Ultimate-2012-Finding-and-managing-cloned-code-JPN

IntelliTrace​

トラブルシューティングで、なかなか事象が再現できず困ったとき、実行中に発生している例外やイベントからヒントを得る必要があります。
そんなときは、IntelliTraceの機能を使うと後から問題のあった箇所の呼び出し履歴を確認できます。
どのメソッド呼出で例外が起きるのか、ステップ実行して追跡する必要はありません。

また、私は試したことはありませんが、下記のように開発者以外のPCにおいてもイベント収集が可能となっています。
ユーザー環境にリリースした後、ユーザーサポートの対応中にどうしても事象を再現できず解決に至らない場合、こういったツールが力を発揮するかも知れません。

IntelliTrace には、Visual Studio を接続できない他の環境に配置できる、スタンドアロン コレクターもあります。
インストール処理を実行しないので、管理者の抵抗を受ける心配は不要です。
ターゲット環境にコレクターをコピーできるかどうかかどうかだけが問題です。
コレクターでは、アプリケーションの実行が .itrace ファイルに記録されます。
開発者はこのファイルを開発コンピューターに転送して Visual Studio で開くことができます。
このシナリオは、デバッグ中にアプリケーションの実行を制御できないので、"非ライブ デバッグ" と呼ばれます。
IntelliTrace スタンドアロン コレクターの使用法に関する最新情報については、aka.ms/itracecollector (英語) を参照してください。

https://msdn.microsoft.com/ja-jp/magazine/dn973014.aspx

コード マップ デバッガーの統合​

Professional で利用可能な CodeLens 機能は、該当するクラスやメソッドの利用箇所を表示してくれます。
コードマップは、この表示をさらにグラフィカルに表示し、影響範囲の全体像を確認することが可能です。

https://msdn.microsoft.com/ja-jp/library/jj739835.aspx

.NET メモリ ダンプ分析​

.NET アプリケーション(4.5以上が対象)のヒープメモリデバッグを行う機能です。
メモリ利用状況に意図しない問題が発生している場合、メモリダンプを取得してどのオブジェクトがメモリを使用しているか、適切なGCが行われているかといった確認を行うことができます。

https://msdn.microsoft.com/ja-jp/library/dn342825.aspx

Live Unit Testing​

2017の目玉機能の一つです。

TDD(テスト駆動開発)を進めるために、まず単体テストを書き、その単体テストをパスするための最低限のプログラムコードを書き、
全てのテストが通るようになったらリファクタリングを行い、リファクタリングが終われば次の機能の単体テストを書く、、、
というサイクルにおいて、 Live Unit Testing を有効にしておくと、書いたコードによってテスト結果がどう変わったかをリアルタイムに評価してくれます。

開発コストを下げるためには、なるべく早い工程で間違い(バグ)を検出して修正してしまうことが有効であると言われており、事実コストにも如実に反映します。

もしもユーザーにリリースした後に問題が発覚すれば、コードの修正だけではなく影響調査を行い関連する範囲も含めた再テストや、
再リリース(社内規定に従ったリリース手続きの再実施)、ユーザー周知など、作業だけでも大変な手戻りが発生するとともに、
信頼の低下、ユーザー離れなど、ビジネスの機会損失にも繋がりかねません。

いかに開発の早い段階で問題を検出するか、という取り組みは
ShiftLeft と呼ばれており、プロジェクト管理界隈でも標準的な考え方として取り入れられています。

慣れないうちは、単体テストから機能を作っていく作業を煩わしく感じてしまいついつい機能から先に作って、後からテストを作成するといった進め方に
なってしまうことが多いと思われますが、単体テストを先に書くことで、何を意図した機能なのかが明確になり、テスト可能な形で処理分割を強制されるため、
自ずと単一責務の原則(SOLID原則のS)を意識したコードになります。

Live Unit Testing が無いときは、単体テストが通ることを定期的に実行して確認しなくてはなりませんでした。
この機能によってリアルタイムでテストが行われて結果が表示されるため、どの修正によってテストが通らなくなったのかが瞬時に判明します。

ぜひ、試用版で効果を確認してみて下さい。

テスト ケース管理​

TFSのテストマネージャありきの機能になりますが、特定機能のテストシナリオに対して単体テストを紐づけて管理することが可能になります。
バグ修正後のリグレッションテストなどで効果を発揮する機能と言えます。

https://msdn.microsoft.com/ja-jp/library/dd380741.aspx

Web ロードおよびパフォーマンス テスト​

Webアプリケーションに対して、負荷テストを行うことができます。
ブラウザアプリケーションだけでなく、WebAPIに対しても負荷の高い状態でどの程度のパフォーマンスが出るのか計測することができます。

この機能は主にサーバサイドのパフォーマンスを計測するもので、クライアントサイドのパフォーマンスは他の方法で計測を行う必要があることに注意してください。

IntelliTest​

Live Unit Testing の項では、先に単体テストコードを書くことの重要性について説明しました。
しかし、既に商用としてリリースされているアプリケーションで、テストカバレッジが低い上に単体テストが書きにくいアプリケーションを預かり
メンテナンスしなければならないケースもあると思います。

そういった場合に、機能を追加したり、リファクタリングを行うだけで既存の機能を壊してしまうことが往々にして発生します。
これを防ぐためには、既存のコードに対して単体テストを書いてから修正を行うというアプローチが考えられます。

しかし、これを手作業で行うには思ったよりも手間がかかります。
まず、テストが成功したとしても本当に仕様通りなのか判断することができず、密結合されたクラスがあれば、影響箇所全てのテストを書く必要があり、
もし一部のクラスについてテストを書かなかった場合に、致命的な影響が出ていても気づくことができません。

そこで、これまでに紹介した機能を使って修正対象のクラスを参照するすべての箇所について、
IntelliTest を使って単体テストを自動生成することで、少しでも修正による不具合発生のリスクを低減することが可能です。

https://msdn.microsoft.com/ja-jp/library/dn823749.aspx

Microsoft Fakes (単体テストの分離)​

当たり前の話ですが、単体テストは製品版のコードが記述されるまで「失敗」状態から変わることはありません。
(もしコードを書かずに「成功」となるテストがあれば、 それは単体テストで保障すべき振る舞いではありません)

しかし、開発の規模によっては、計画上一部の機能は仕様が未確定で、既に仕様が確定した機能から開発するといったことがあります。
その場合、仕様検討中の機能を前提とした他の機能の単体テストは、前提とする機能が完成するまでテストが「成功」になることは無いのでしょうか？

いいえ、そんなことをやっていたら非効率です。
そもそも、単体テストで保障するのは「単体」レベルの機能の振る舞いであって、他の機能と結合したときの動作ではありません。

Microsoft Fakes は、まだ未完成の機能や、単体レベルのテストにおいて
実際に処理を行う必要が無い機能(WebアクセスやDB操作等)を代替する手段を提供します。

具体的には、テスト対象機能が必要とする具象クラスを、偽装したクラスで置き換えます。
※例えばWebページのアクセスを偽装して、毎回固定のレスポンスを返すなど
こうすることで、先に実装した機能の責任範囲だけを単体テストで保障することができ、
後で他の機能が完成したときに、具象クラスに置き換えても動作することを確認できます。

https://msdn.microsoft.com/ja-jp/library/hh549175.aspx

NuGetでも、Moqという代替オブジェクトを生成するライブラリが公開されています。
Microsoft Fakes はお手軽自動生成、Moqは自由に具象クラスを定義して使うイメージで、どちらが使いやすいかはお好みですね。

https://github.com/moq/moq4

コード カバレッジ​

記載したコードの動作を単体テストでカバーしている割合を分析します。 カバレッジが品質に与える影響は、一定の割合で頭打ちになると言われており、100％に近づけば近づくほど品質が向上するといったものではありません。

カバレッジを取得する目的として、「機能を追加したが、単体テストは書いていない」といったコードコミットをカバレッジの低下によって察知し、
マージ前にコードの品質を推察できるようにすることです。

テストを追加せずに機能を追加すれば、カバレッジは低下し、そのコードの品質も評価はできない (良くはない)と言えます。
カバレッジを分析して、修正によってカバレッジが低下しないことを品質向上のための取り組みとしましょう。

Lab Management​

こちらもTFSありきの機能です。開発したアプリケーションの検証環境構築をサポートする機能なのですが、
簡単なサンプルを使った検証が難しく、動きを確認できていないため、説明は省略させてください。

https://msdn.microsoft.com/ja-jp/library/dd936084.aspx

コード化された UI テスト​

結合テストレベルのテストをコードで記述して自動実行します。
UIの操作を記録して、テストコードを自動生成することも可能です。

https://msdn.microsoft.com/ja-jp/library/dd286726.aspx

個人的には、MsTestベースで利用できる Friendly もおすすめです。
Friendlyテストプロセスから、テスト対象のプロセスのメソッド、プロパティ、フィールド全て我が物のように使う事ができます。

Friendly・・・お前のものはおれのもの。おれのものもおれのもの。だっておれたち ともだち (Friendly) だろう？
http://www.codeer.co.jp/AutoTest

クロス プラットフォーム開発​

主に、Xamarinを拡張するための機能です。

埋め込みアセンブリ​

相互運用機能型の情報をアセンブリに埋め込みます。

Xamarin Inspector​

Xamarinアプリケーションの詳細なデバッグを行うことができます。
https://developer.xamarin.com/guides/cross-platform/inspector/

Xamarin Profiler​

Xamarinアプリケーションのプロファイリングを行うことができます。
IntelliTrace まではいきませんが、アプリのパフォーマンスに関わる情報や、メモリ・オブジェクトの利用状況を確認することができます。
http://ytabuchi.hatenablog.com/entry/2016/08/18/233000

Remoted iOS Simulator for Window​

Windows上で iOS アプリのシュミレーションが可能になる機能です。
Visual StudioがMacに少なくとも1回は接続されていることが前提となっているため、純粋にWindowsしか無い場合は利用できませんのでご注意ください。

https://developer.xamarin.com/guides/cross-platform/windows/ios-simulator/

まとめ​

• PC台数250台以上、または売上1億円以上ならProfessional以上のエディション必須
• CodeLens を使いたいなら Professional
• テストの自動生成など、品質向上機能を使いたいなら Enterprise

はっきり言って Enterprise のお値段は非常に高いですが、機能は本当に優れていて購入代金以上のメリットを得られる可能性があります。

Visual Studio 2017 の新機能については、こちらをご確認ください。