日本語テストメソッドについて

日本語テストメソッドについて
どう思いますか？
Id : @kumake1004

Agenda
1. 今日話すこと話さないこと
2. 日本語テストメソッドを使う理由
3. 使ってみた感想
4. Web 上の意見
5. まとめ

今日話すこと
* なぜ日本語テストメソッドを使いた
いのか
* Web 上の人たちは日本語テストメ
ソッドについてどう思っているか
* 自分で使ってみた感想と注意点

今日話さ(せ)ないこと
* TDD, BDD, SDD(ATDD) などの
テスト手法に関する話
* テスティングフレームワークや
ツール
* .NET に関係すること(えー

今日知って欲しいこと
考えて欲しいこと
* 肯定派、否定派の主張
* 日本語テストメソッドの注意点
* あなたなりの意見

なぜ日本語テストメソッドを
書くのか？

なぜ日本語？
1. わかりやすい
2. テストメソッド名から曖昧さがな
くなりやすい

ダメな例
[Test]
public void TestGetData()
{
}

テストメソッド名から
何も読み取れないのでダメダメ
[Test]
public void TestGetData()
{
}

ASP.NET MVC の例
※MvcHtmlStringTest.cs
[Fact]
public void ToStringReturnsEmptyStringIfOriginal
StringWasNull ()
{
// Null から MvcHtmlString インスタンスを
// 生成した時、ToString() が
// String.Emptyを返すことを確認しています
}

分かってみれば納得ですが、
ぱっと見では少し分かり難いです
[Fact]
StringWasNull ()
{
// Null から MvcHtmlString インスタンスを
// 生成した時、ToString() が
// String.Emptyを返すことを確認しています
}

Entity Framework の例
※DatabaseInitializerTests .cs
[Fact]
public void
DropCreateDatabaseIfModelChanges_throws_if_database_e
xists_and_model_does_not_match_with_Migrations_enable
d()
{
// DB マイグレーションが有効に設定してある場合、
// DB が既に存在し、かつ EF が認識しているモデルと
// DB スキーマが異なると例外がスローされることを確認
}

非常に分かりやすいです
日本語じゃなくてこれでも
良いかも知れません
[Fact]
public void
DropCreateDatabaseAlways_throws_when_given_a_nu
ll_context ()
{
// DropCreateDatabaseAlways インスタンスの
// InitializeDatabase メソッドに null を渡すと
// 例外がスローされることを確認しています
}

日本語の例(ASP.NET MVC)
[Fact]
public void nullから生成した時はToStringがnull ()
{
}
[Fact]
StringWasNull ()
{
}

日本語の例(Entity Framework)
[Fact]
public void DBマイグレーション有効時
DropCreateDatabaseIfModelChangesはDBが存在しかつス
キーマが異なると例外をスローする ()
{
}
[Fact]
public void
DropCreateDatabaseIfModelChanges_throws_if_database
_exists_and_model_does_not_match_with_Migrations_en
abled()
{

分かりやすくなりましたね
※そうでもない？

日本語にするメリット
1. わかりやすい
くなりやすい

英語だと
* 語彙に限りがある
* 文法を知らなかったりする
* プロダクトコードと意味が被る
ので、メソッド名が曖昧になったり、
(最悪)普通に読めなかったりします。

実例
// とあるコレクションクラスのメソッドをテスト
[Test]
public void MethodShouldReturnSelected()
{
}
“Selected” から何を想像しますか？

正解
enum HogeEnum
{
Selected,
NotSelected,
//...
}

大分恣意的な例ですが、
実際に起こった例でした

例えば日本語なら
[Test]
public void メソッドは選択した要素を返すべき()
{
}
[Test]
public void メソッドはSelectedを返すべき()
{
}

テスト設計の問題にも
気付きやすくなります

[Test]
public void ShouldReturnErrorIfPassInvalidArgs()
{
}
[Test]
public void 不正な引数が渡された時はエラーを返すべき
()
{
}

[Test]
public void ShouldReturnErrorIfPassInvalidArgs()
{
}
[Test]
public void 不正な引数が渡された時はエラーを返すべき
()
{
}
条件や求めている結果が曖昧

Agenda
1. 今日話すこと話さないこと
2. 日本語テストメソッドを使う背景
3. 使ってみた感想
4. Web 上の意見
5. まとめ

スクラッチから書く小規模
プロジェクトを任されたので、
日本語テストメソッドを試して
みた感想。

実感したメリット
1. ちゃんと書けば、自分の書いたテ
ストは、読んだ時に圧倒的にわかり
やすい
くなる(テスト設計になる)

実感したデメリット
1. メソッド名に本人の癖が出やすい
+ 自由度が高いので、他人のテス
トが読めない
2. 冗長になりがち

冗長になりがちとは
[Fact]
public void
DropCreateDatabaseAlways_throws_when_given_a_n
ull_context ()
{
}
[Fact]
public void DropCreateDatabaseAlwaysはDbContext引
数にnullを渡されると常に例外をスローする ()
{
}

結論
言うほど悪くないが、
日本語一辺倒にならないようにしたり
他人と一緒にやるときはルールが欲しい

気をつけたいこと
1. 名前空間やクラス名も活用する
2. 説明しすぎない
3. フォーマットを統一する

コンテキストをメソッド名に
含めると、長くなりがち
[Test]
public void ○○が□□で、△△が××の条件の時にhoge
するとfugaから例外をスロー ()
{
}

名前空間やクラス名にも
日本語で事前条件や制約を
記述して構造化
namespace ○○について
{
public class □□の条件の時
{
public class △△が××なら
{
[Test]
public void hoge ると例外をスロー ()
{
}
}
}
}

なまじ語彙や文法の制約が
なくなるので、
過剰に説明しがちになります
[Test]
public void 正常系テスト_MyClassのEnabledプ
ロパティがfalseの時にMethodが呼ばれると
SelectorClassのIsValidプロパティにfalse
がセットされたHogeクラスをreturnすべき ()
{
}

普段から注意すると共に、
構造化やパラメータ化テスト、そも
そものテスト設計
見直しなどを考えましょう
[Test]
public void 正常系テスト_MyClassのEnabledプ
ロパティがfalseの時にMethodが呼ばれると
SelectorClassのIsValidプロパティにfalse
がセットされたHogeクラスをreturnすべき ()
{
}

フォーマットがバラバラだと
その人の文章の癖が出やすいです
[Test]
public void ○○が□□の時に△△が例外をスローする
{
}
[Test]
public void もし○○に□□がセットされている場合△△から
例外がスローされるべき
{
}

非常に読みにくいので、
事前にチームで簡単なルールを
定めておくと良いと思います
例
* ○○する、○○すべき
* ○○の場合、○○の時
* 設定されている、セットされている
* 文の組み立てかた
など

ソース
* テストメソッドを日本語で書くことについて - togetter
http://togetter.com/li/514903
* 読書会(Junit実践入門)第1回議事録
http://www.javareading.com/bof/junit1.html
* [Java] 内部的にunicodeだから日本語つかえるけど・・・いくら英
語苦手だからって・・・ - ウンコードマニア
http://unkode-mania.net/view/5029e1a9eef2c7f861000008
* その他多くのブログ
※全てがテストコードについて語っている訳ではありません。

否定派
├─とにかくコードに日本語は使っちゃだめだよ派(原理主義)
│ ├─個人の趣味を持ち込まないでくれるかな、こんなコードを規約で認める現場があると思う?
│ ├─信じられない、見た目がキモイ
│ └─日本語アリって言う人、動けばいいって考え方なのかな。
├─問題起こるからやるなよ派(穏健派)
│ ├─フレームワークやツールによっては使えない可能性があるよ
│ ├─英語が社内公用語になれば確実に改修対象になるからやるなよ(楽天派)
│ └─海外にオフショアできなくなるよ
├─日本語使いたいならなでしこ使おう(過激左派)
├─ローマ字でメソッド書けば？(過激右派)
└─良く分かってない人が変な難癖付けてくるよ派(事なかれ主義)
肯定派
├─日本語でもいいんじゃない(穏健派)
│ ├─自分は書かないけど、テストコードで他の人が書く分には止めないよ
│ └─テストコードは呼び出すのでもないのが普通だし、日本語でも問題は感じないよ
├─積極的に日本語にしよう(主流派)
│ ├─何をテストしているか分かりやすくなるよ
│ ├─日本語メソッド名を禁止すると説明不足な英語かローマ字メソッド名になるだけだと思う
│ └─海外にオフショアされるのを妨害できる
├─日本語の方がマシだよ派
│ ├─1テスト対象に複数テストメソッド用意する事は珍しくない。全部英語でなんて書いてられない
│ └─連番にしたりなんちゃって英語にして日本語コメントで補足するよりマシ
└─C#は数字で始まるメソッド名や、メソッド名に句読点を使えないのがクソ(でもC#は嫌いだよ派)

否定派
│ ├─個人の趣味を持ち込まないでくれるかな、こんなコードを規約で認める現場があると思
う?
│ └─日本語アリって言う人、動けばいいって考え方なのかな
│ ├─フレームワークやツールによっては使えない可能性があるよ
他に
*入力がめんどくさい(IME)
*ソース(テストコード)を綺麗に書く方がよい
*ユニットテストのテスト仕様を見て誰得なの？
*ただただ美しくない
など。感情的に否定する人の多い派閥。
気持ちは分かる。

否定派
う?
│ ├─フレームワークやツールによっては使えない可能性がある
他に
*メソッド名でテスト内容を表現するのは中途半端ではないか？
テストケースの定義(テストの入力、期待値)とメソッド名を
紐付けるような仕組みが必要では？
*テスト内容はメソッド名じゃなくて javadoc に
切り出せばいいと思う
など。概ねリスクを天秤にかけた結果だったり、
別の方法で実現すべきといった(一部除き)冷静な派閥。

否定派
う?
過激派。
もしくはそもそも議論をする気がない派閥。

否定派
う?
過去にトラウマがあると思われる派閥。
スタティックおじさんなどの話もあるので
気持ちはよく分かる。

肯定派
│ ├─1テスト対象に複数テストメソッド用意する事は珍しくない。全部英語でなんて書いてられ
ない
自分や他人に積極的な利用は勧めないが、
否定するつもりもない穏健派。

肯定派
ない
積極的に推進する派閥。
論拠はやはり「わかりやすい」。

肯定派
ない
「日本語にするメリットがあるから」というより
「英語にするよりマシ」という主張の派閥。

肯定派
ない
＿人人人人人人＿
＞突然の C# dis ＜
￣Y^Y^Y^Y^Y^Y￣

Web 上の意見まとめ
## 否定派
* そもそも日本語を使って欲しくない
* 移植性やフレームワークに対するリスクを取れない
* オフショアなど日本人以外との開発に問題
* 「わかりやすさ」に求められる要件は別の形で満たすべき
## 肯定派
* メソッドに日本語ダメなのにコメントは日本語いいの？
* わかりやすい
* 無理な英語よりマシ
* やるにしても、チームとの合意を取るべき

まとめ
* 日本語テストメソッドは分かり易さやテスト設
計の問題に気付けるというメリットがあります
* 食わず嫌いせず、一度使ってみてください
* ただ、どうしても嫌いという人もいるので、仕
事で使う時はチーム内で合意をとりましょう
* 注意すべき点があります。仕事で使う時は事前
に簡単な規約を定めると良いです

ご清聴
ありがとうございました

日本語テストメソッドについて

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Último

Último (9)

日本語テストメソッドについて