Unit Testの書き順(3)
書き順を守っていると、expectedとinputの所にそのテストの本質が書かれます。 本質が分離されていると良い事は幾つかあります。 保守がしやすい、というのがそのうちの一つです。 まず、読みやすい。 expectedとinputを読むだけでテストの内容が理解出来る為、コードを読む必要はほとんど無くなります。 英語で説明的に書かれている為、他人の作ったUnit Testを一通り理解するのも圧倒的に楽です。 テストのinputとexpectを読めば一通りテスト対象のクラスの仕様も分かります。 Mockのsetup等手順が大きくなればなるほどテストの可読性は落ちますが、そこがexpectやinputと分離されていると、全て読まなくてはいけない場合でもだいぶ楽になります。 また、本質はあまり変更されません。 コンストラクタの引数が変わったり、テストに必要な何かが変わる事はあり得ますが、inpu
Unit Testの書き順(2)
Unit Testを書く時に書き順を固定する一番のメリットは、考えなきゃいけない事を減らす事です。 最初の真白な状態からテストを書くのは、結構難しい作業です。 特にテスト対象がまだ分かっていない時に、突然スラスラとテストが書けるか、というとなかなか難しい。 そこで真白な状態から書かなくてはいけない範囲を、テスト全体からexpectedとinputの数行に絞る訳です。 expectedとinputはそれなりに同時に考える場合が多いのですが、それでもテスト全体を書く事に比べるとずっと考える事は少なくて済みます。 expectedとinputが書き終われば、そこから先は単純作業です。 実際、VSのUnit Testの自動生成を普段から使っていれば、この形に近い状態まで生成してくれる事がわかると思います。 これはつまり、機械的にできる作業だ、という事です。 また、変数にするのは自分の考えを整理する
Unit Testの書き順(1)
私が概ね全てのお仕事コードにUnit Testをつけるようになって、だいたい3年になります。 Testabilityという物に高い意識を持つようになった期間とだいたい一致している為、Unit Testを書くという事自体のキャリアもまだ3年です。 プログラムを書くという事だともうすぐ10年になりますが、Unit Testはようやく素人の域を脱した程度の所です。 まだまだそんなレベルではありますが、それでも3年続ければ3年続けただけの物もあります。 その一つとして、Unit Testの書き順という考え方があります。 Unit Testを書く時に、最初に何から書くでしょうか？ 私は expectedの変数 inputの変数 その他 という風に書きます。1と2は入れ替わる事もあります。例を挙げましょう。 function Adder() { return {add: function(a, b)
SambaがGPLv3に移行 | スラド
Open Tech Pressの記事によれば、Sambaが将来のリリースを全てGPLv3およびLGPLv3へ移行することを決定したとのことだ。次に予定されていた3.0.26が3.2.0に置き換わり、3.2.0以降がGPLv3採用版となるらしい。 記事でも書かれているが、MicrosoftはGPLv3に縛られないと明言したものの、この記事でインタビューに答えているSamba開発リーダーであるジェレミー・アリソン氏の前在籍企業であるNovellには早くも試練かもしれない。Windowsと密接な関わりがあるSambaがGPLv3に移行というのは実に興味深いが、これによってGPLv3に移行する向きも随分と加速しそうである。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
