分とかで回している感じになります。テストケースがいくつか追加されており、実装もリファクタリングによってわかりやすくなっています。属性を導入したことによって、無駄に行数を増やさずにテストケースを追加できています。7d57この時点のテストを抜粋します。Is.EqualTo(expected));}また重複が目につくようになってきましたので、テストコードをリファクタリングすることにしました。使っていませんし、常に固定でも問題ありませんので、ヘルパメソッドを使うようにしました。}さらにリファクタリングを続けます。受け取るようになりました。タブ文字で連結すればいいことになります。つのメソッドを導入したことでテストコードはこうなりました。body)));}重複が消え去った上、どういったテストケースなのかが非常にわかりやすくなりました。95774実装をとりあえず終えた段階ですが、今度はテストメソッドの中の重複が気になってきました。個所で使われています。ここもリファクタリングしてしまいましょう。メソッドを追加しました。body));}これによって、テストメソッドの中はこうなりました。expectedCategory);いい感じです。つのメソッドハッシュタグ付きのTweetがHashTagに判定されるリプライ付きのTweetがReplyに判定されるメンション付きのTweetがMentionに判定されるを一つのメソッドにまとめることもできるのですが、これらはテストケースとしては別物だと思っているので、まとめていません*6。6ff2とりあえず書いてみたものの、テストメソッドが微妙です。result));}パッと見てこれがなんのテストなのか全くわかりません。これはダメだと思い、判定結果を表すクラスを導入してみることにしました。いうクラスを導入しました。つぶやき本体と判定されたカテゴリを持つだけの単純なクラスです。これによって、結果の文字列が等しいことを確認するテストと、判定されたカテゴリが正しいことを確認するテストを分離することができそうです。f7ccここからコードを置き換えていきます。あるので、安心して置き換えを試してみることができます。使って書き直してみました。コンパイルは通りません。メソッドを書き換えます。して扱っているテストが残っているため、コンパイルが通りませんでした。無効化しちゃいました。あとはテストを書き換えていって、無効化した範囲を狭めていきます。テストコードのリファクタリングを行って、重複部分をかなり削っていたため、置き換えは非常に簡単に行うことができました。導入することでどうなったか見てみましょう。Is.EquivalentTo(expectedCategories));}非常にすっきりしたテストになりました。順番を考慮しない比較を行ってくれます。導入したことによりその必要がなくなりました。そのため、テストの追加が非常に簡単にできるようにもなっています。福岡では、ここで入力形式の変更という仕様変更が入りました。間にタブ文字が置かれます。タブ文字で区切られた形式です。この変更に対応するために、とりあえずテストをひとつ修正してみます。・・・あれ?仕様変更の影響を受けていない?と思いつつ、ほかのテストも新形式に修正してみました。リプライ判定用の正規表現で、先頭にマッチという条件が含まれていました。期待しているテストがことごとく落ちました。部分の取得方法を修正し、新形式への対応完了です。するという部分が目についたので、リファクタリングを行うことにしました。この際、チケットとして分けるのが面倒なので同じチケット内でやってしまうことが多いです。本来の作業に入ります。分くらい使っています。