私はCastleスタックでC#で開発しています。私は単体テストを始めたばかりで、より柔軟な言語 (C# よりも) を使用すると、テストの記述が容易になる可能性があると聞いたことがあります。
単体テストを書くためだけに Boo を学ぶ価値はあると思いますか?
私たちは SharpDevelop IDE を使用しているので、Boo サポートが利用可能です。新しい CLR 言語を学ぶ言い訳を探していましたが、単体テストの学習の邪魔になりたくないだけです。
私はCastleスタックでC#で開発しています。私は単体テストを始めたばかりで、より柔軟な言語 (C# よりも) を使用すると、テストの記述が容易になる可能性があると聞いたことがあります。
単体テストを書くためだけに Boo を学ぶ価値はあると思いますか?
私たちは SharpDevelop IDE を使用しているので、Boo サポートが利用可能です。新しい CLR 言語を学ぶ言い訳を探していましたが、単体テストの学習の邪魔になりたくないだけです。
Booをテスト言語として実際に活用するには、Spectre ( Boo DSLとして実装されたBDDフレームワーク)を見てください。それ以外の場合は、 xUnitを使用する別のCLR言語です。
ユニットテストを始めたばかりの場合は、Eskoに同意します。C#+ NUnitを使用するだけで、より多くの情報とサンプルコードを見つけることができます。
これはWebプロジェクトですか?Booを学ぶためのもう1つの良い言い訳は、Brailビューエンジンを使用することです(元々はMonorailからのものでしたが、現在はASP.NET MVCでも利用できます) 。
単体テストに慣れていない場合は、少なくとも基本を制御できるようになるまで (おそらく 2 週間) は、使い慣れた言語を使用することをお勧めします。使用している言語/フレームワークが冗長または制限的すぎると感じた場合は、別の方法を試してください。
私は主に Java で開発していますが、Scala に移行する予定です。将来的には、アプリケーション コードの一部を Java で記述する可能性もありますが、テストには、Scala、Ruby、Groovy、またはより柔軟な構文を持つ同様の言語を使用したいと考えています。たとえば、Java/C# ではテストに長い説明的なメソッド名を使用する必要がありますが、より柔軟な言語では単純な文字列だけを使用できるため、テスト名がはるかに読みやすくなります: http://www.codecommit.com /blog/java/the-brilliance-of-bdd
それがあなたの会社で政治的に実行可能であるならば、おそらく。通常、コードのテストは本番コードよりも結合度がはるかに低いため、使用されている言語で遊んだり探索したりすることができます。これは、新しい言語を手に入れるのに良い環境になります。