読者です 読者をやめる 読者になる 読者になる

PoohSunny's blog

生きるために食べるのか、食べるために生きるのか。

xUTPの著者から教えてもらった「テストのクラフトマンシップ」

はじめに

これはRecruit Engineers Advent Calendar 2016の11日目の記事ですが遅れての投稿です。すみません。 先日、xUTPの著者のセッションに行って聞いたきたので、その内容をまとめたものです。

謝辞と注意点

この記事を書くに際し、セッションのスピーカーであるGerard Meszarosさんに、特別にスライド内のコードの利用を認めていただきました*1。この場を借りて感謝いたします。Thank you for giving me the right to use code sample in Agile Singapore 2016 presentation, Mr. Meszaros!

上記の経緯から、以下に出てくるコードのライセンスはCopyright 2016 Gerard Meszarosです。ご注意ください。

Unit Test Craftmanship概略

スピーカーについて

Gerard Meszarosさんです。 この人は『xUnit Test Patterns: Refactoring Test Code』という本*2の著者として有名な人です。

セッションの資料

本編

みんな「上手く」テストしてる?

アイスブレイク的にGerardさんが問いかけます。 「ユニットテストしてる人てをあげてー!」 個人的にはここですごく驚いたのですが、聴衆の9割近くが手をあげてました。恐るべしシンガポール。しかしGerardさんは続けます。

上手にできてる人は?」

ここで手が挙がる人は1割くらい。みんなユニットテストでは苦労してるんですね。 というわけで、ここから上手なテストをするためのクラフトマンシップの話が始まります。

変更に強いテストを作るには?

プログラミングの経験と、xUnit(例えばJUnitみたいな)の経験、それにテストの経験、これがあれば変更に強い自動テストが作れるだろうか? NOだ。それだけでは不十分。そこからメンテナンス性の高いテストを書く前段として、プロダクションコードとテストコードを比較しながら、テストコードにはどう言ったポイントが重要なのかを説きます。

個人的にとても興味深かったのは、下記の2点です。

  • Reusability(再利用性)は、プロダクションコードでは重要だけれど、テストコードでは重要ではない。テストはそれぞれコンテクストがあるから、再利用は重要ではないとのこと。
  • Simplicity(簡潔さ)は「Crucial(決定的)」。なぜかというと、「だってテストコードのテストはしたくないでしょ?」とのこと。そりゃごもっとも。

ちなみにこの後実例を挙げながらテストのリファクタが始まるのですが、上記の2点はリファクタする上での結構重要な指針を授けていると感じました。

実例、テストのリファクタの開始

実例として、サンプルコードを元に説明していきます。題材になったのはインボイスのサービスの、あるメソッドのテストの話です。

最初はこんな感じ。不吉な感じが漂います。

public void testAddItemQuantity_severalQuantity () throws Exception {
    try {
        // Setup Fixture
        final int QUANTITY = 5;
        Address billingAddress = new Address("1222 1st St SW", "Calgary", "Alberta", "T2N 2V2",
                "Canada");
        Address shippingAddress = new Address("1333 1st St SW", "Calgary", "Alberta", "T2N 2V2",
                "Canada");
        Customer customer = new Customer(99, "John", "Doe", new BigDecimal("30"), billingAddress,
                shippingAddress);
        Product product = new Product(88, "SomeWidget", new BigDecimal("19.99"));
        Invoice invoice = new Invoice(customer);
        // Exercise SUT
        invoice.addItemQuantity(product, QUANTITY);
        // Verify Outcome
        List lineItems = invoice.getLineItems();
        if (lineItems.size() == 1) {
            http://singapore2016.xunitpatterns.com 14 Copyright 2016 Gerard Meszaros
            if (lineItems.size() == 1) {
                LineItem actualLineItem = (LineItem)lineItems.get(0);
                assertEquals(invoice, actualLineItem.getInvoice());
                assertEquals(product, actualLineItem.getProduct());
                assertEquals(quantity, actualLineItem.getQuantity());
                assertEquals(new BigDecimal("30"), actualLineItem.getPercentDiscount());
                assertEquals(new BigDecimal("19.99"), actualLineItem.getUnitPrice());
                assertEquals(new BigDecimal(“69.96"), actualLineItem.getExtendedPrice());
            } else {
                assertTrue(“Invoice should have exactly one line item“, false);
            }
        } finally {
            deleteObject(expectedLineItem);
            deleteObject(invoice);
            deleteObject(product);
            deleteObject(customer);
(略)

きっと値について質問あるよね! ってなりました。

テストのリファクタリング

ここから鮮やかなテストのリファクタリングが始まります。

まずは分解する

まず、このテストがそれぞれどんなパーツをもっているのか、というのを4フェーズテストを使って分離していきます。ざっくり

  • でっかいGiven(前提のセットアップ)があって
  • Whenは invoice.addItemQuantity(product, QUANTITY);の部分だから、When we call addItemQuantityかな
  • でっかいThenがある

と言った感じ。個々のステップごとに見ていきます。

Thenの改善

「鈍い」アサーションを直す

まず取りかかったのが、「鈍い(Obtuse)」アサーションを修正することでした。上記コードだと

} else {
    assertTrue(“Invoice should have exactly one line item“, false);
}

この部分。これを

} else {
    fail("invoice should have exactly one line item");
}

として、はっきりとテストがFailすべき場面であることを明示しました。

ハードコードされたデータの削除

assertEquals(new BigDecimal("30"), actualLineItem.getPercentDiscount());

これはテストをもろくするので、Expected Objectを用いてハードコードされたデータをはじき出します。 下記のように。

LineItem actualLineItem = (LineItem)lineItems.get(0);
LineItem expectedLineItem = newLineItem(invoice, product, QUANTITY, product.getPrice()*QUANTITY );
// 略
assertEquals(expectedLineItem.getPercentDiscount(), actualLineItem.getPercentDiscount());

これでハードコードは取り除かれましたが、今度はアサーションが冗長になってきています。

カスタムアサーションで冗長さを解決

上記のように冗長になってしまったアサーションを、カスタムアサーションを読んでシンプルにします。

LineItem actualLineItem = (LineItem)lineItems.get(0);
LineItem expectedLineItem = newLineItem(invoice, product, QUANTITY, product.getPrice()*QUANTITY );
assertLineItemsEqual(expectedLineItem, actualLineItem);

Gerardさんはカスタムアサーションをよく使うって言ってました。理由としては、カスタムアサーションにはそのテストが書けるから。あとはテストする文脈だと、既製品のマッチャーよりも、コンテクストに応じて作りこんだ方が良いものになる経験が多いから、と記憶しています。これについては後でまた出てきます。

Guardアサーションでテスト内の条件を削除

さて、ここまででだいぶテストコードは綺麗になってきました。

List lineItems = invoice.getLineItems();
if (lineItems.size() == 1) {
    LineItem actualLineItem = (LineItem)lineItems.get(0);
    LineItem expectedLineItem = newLineItem(invoice, product, QUANTITY, product.getPrice()*QUANTITY );
    assertLineItemsEqual(expectedLineItem, actualLineItem);
} else {
    fail("invoice should have exactly one line item");
}

次に気になってくるのは、テスト内に入っているif分です。このif文をGuard Assertionを使って削除します。

List lineItems = invoice.getLineItems();
assertEquals("number of items",lineItems.size(),1); // ここに Guard Assertionを入れる
LineItem actualLineItem = (LineItem)lineItems.get(0);
LineItem expectedLineItem = newLineItem(invoice, product, QUANTITY, product.getPrice()*QUANTITY );
assertLineItemsEqual(expectedLineItem, actualLineItem);

ここまでで一旦Thenのリファクタは落ち着きます。

Givenの改善

続いてGivenの改善に進みます。まずはハードコードされたテストデータを取り除きます

ハードコードされたテストデータの削除

問題になっているのは下記の部分

final int QUANTITY = 5;
Address billingAddress = new Address("1222 1st St SW",
        "Calgary", "Alberta", "T2N 2V2", "Canada");
Address shippingAddress = new Address("1333 1st St SW",
        "Calgary", "Alberta", "T2N 2V2", "Canada");
Customer customer = new Customer(99, "John", "Doe", new
        BigDecimal("30"), billingAddress, shippingAddress);
Product product = new Product(88, "SomeWidget", new
        BigDecimal("19.99"));
Invoice invoice = new Invoice(customer);

まずは小さいステップとして、データの作成を別メソッドに任せます

final int QUANTITY = 5 ;
Address billingAddress = new Address(getUniqueString(),
        getUniqueString(), getUniqueString(),
        getUniqueString(), getUniqueString());
Address shippingAddress = new Address(getUniqueString(),
        getUniqueString(), getUniqueString(),
        getUniqueString(), getUniqueString());
Customer customer = new Customer(
        getUniqueInt(), getUniqueString(),
        getUniqueString(), getUniqueDiscount(),
        billingAddress, shippingAddress);
Product product = new Product(
        getUniqueInt(), getUniqueString(),
        getUniqueNumber());
Invoice invoice = new Invoice(customer);

Creation Methodを使って不要な情報を隠蔽

このgetXXXX系のメソッド、テストと無関係(Irrelevant)な情報だよね。ということで、それらを隠蔽しにかかります。

final int QUANTITY = 5;
Address billingAddress = createAnonymousAddress();
Address shippingAddress = createAnonymousAddress();
Customer customer = createCustomer(billingAddress,
        shippingAddress);
Product product = createAnonymousProduct();
Invoice invoice = new Invoice(customer);

まだ止まりません。上記のうちbillingAddressshippingAddressはやっぱり不要な情報だよねということで消しにかかります。 かくして結果は下記の通り

final int QUANTITY = 5 ;
Customer customer = createAnonymousCustomer();
Product product = createAnonymousProduct();
Invoice invoice = new Invoice(customer);

まだまだ。今度はcustomerが不要や!

final int QUANTITY = 5 ;
Product product = createAnonymousProduct();
Invoice invoice = createAnonymousInvoice()

ここまででGivenはシンプルになりました。

再びのThen

ここまでくると、再びThenの中が気になってきます。

LineItem expectedLineItem = newLineItem(invoice,
product, QUANTITY, product.getPrice()*QUANTITY );
List lineItems = invoice.getLineItems();
assertEquals("number of items", lineItems.size(), 1);
LineItem actualLineItem = (LineItem)lineItems.get(0);
assertLineItemsEqual(expectedLineItem, actualLineItem);

このうち、下記の部分が、「方法論(Mechanics)が意図を隠してしまう」と言います。

List lineItems = invoice.getLineItems();
assertEquals("number of items", lineItems.size(), 1);
LineItem actualLineItem = (LineItem)lineItems.get(0);

カスタムアサーションで意図を明確に

というわけで、下記のようにカスタムアサーションを入れて意図を明確化します。

assertExactlyOneLineItem(invoice, expectedLineItem ); 

この部分は完全にアサーションの作り込みですね。意図を明確化するために、自分でアサーションを作りこんでいく、という発想はとても気に入りました。

ここまで来てテストはこんな感じ

public void testAddItemQuantity_severalQuantity() {
    // Setup
    final int QUANTITY = 5;
    Product product = createAnonymousProduct();
    Invoice invoice = createAnonymousInvoice();
    // Exercise
    invoice.addItemQuantity(product, QUANTITY);
    // Verify
    LineItem expectedLineItem = newLineItem(invoice,
            http://singapore2016.xunitpatterns.com 35 Copyright 2016 Gerard Meszaros
                    LineItem expectedLineItem = newLineItem(invoice,
            product, QUANTITY, product.getPrice() * QUANTITY);
            assertExactlyOneLineItem(invoice, expectedLineItem);
}

元と比べると感動ですよね。

もっと意図を明確に

4フェーズテストからの気づき

ここまでテストをリファクタしてきました。ここで冒頭の方に出てきた4フェーズテストの話を再び引き合いに出します

  • Setup -> Setup or Arrange
  • Exercise -> Exercise or Act
  • Verify -> Verify or Assert
  • TearDown -> いらないはず

記述方式によって、方法論によるか、意図によるかが変わってくるという話でした。 3Aというのが参考になります。

と話が進みます。

専門用語で作り込もう

ここからはさらにテストの意図を明確化するための作り込みが始まります。 テーマは

  • DSLを利用しよう
  • 関連するもののみ記述しよう

です。 まずはテスト名を

public void testAddItemQuantity_severalQuantity () {

から、JUnit4を使って

@Test public void
testAddItemQuantity_severalQuantity () {

からの

@Test public void
addItem_severalQuantity_itemValueIsQuantityTimesProductPrice(){

合わせてThenの中も更新します。

// Then
LineItem expectedLineItem = newLineItem(invoice, product,
        QUANTITY, product.getPrice() * QUANTITY);
assertExactlyOneLineItem(invoice, expectedLineItem);

継続的にリーダビリティを向上させるよう努めること というメッセージつきでした。

// Then
shouldBeExactlyOneLineItemOn(invoice,
        expectedLineItem(invoice, product, QUANTITY,
                product.getPrice() * QUANTITY));

ここが僕の中でセッションのハイライトでした。 まず読みやすさありき、それによってアサートは作りこんでしまう。という意図がとてもよく出ていて感動しました。

さらにGivenの中も改善します。

Product product = createIrrelevantProduct();
Invoice invoice = createIrrelevantInvoice();

からの

Product product = givenAnyProduct();
Invoice invoice = givenAnEmptyInvoice();

ここまでで、このメソッドに対するテストは完了です。 セッションはこの後関連する別テストの話に進むのですが、ここで割愛します。 こちらもとても味がある(特にDSLの作り込みのところ)ので、ご興味のある方は冒頭にリンクを貼ったスライドをご参照ください。

クロージング

Closing Thoughtsとして、下記のことを挙げてシメられました。

  • Are your automated checks helping you deliver value continuously?
  • あなたの自動チェックは価値を継続的に提供する助けになっていますか?
    • Do they help you understand what you need to deliver?
    • それらはあなたが何を提供する必要があるのかを理解する助けになっていますか?
  • Are your checks helping Make Safety a Prerequiste?
  • あなたのチェックは前提条件を安全にするのに役立っていますか?
    • Are they making it safer to change your code?
    • それらはコードをより安全に変更できるようにしていますか?
  • Are they helping you Experiment and Learn Continuously?
  • それらは継続的な経験や学びを得るのに役立っていますか?
    • Fast feedback on impacts of code changes?
    • コードの変更のインパクトに対する素早いフィードバックがありますか?
  • Are you Making People Awesome by automating the checks?
  • あなたは自動チェックによって、他の人々を素晴らしくしていますか?
    • Happy developers and users?
    • 開発者と、ユーザーどちらも幸せですか?

どれも金言ですね。

まとめにかえて

今回のセッションに参加して

  • 意図を何より明確に
  • 明確にするためにDSLを作り込むなどする努力を
  • 何のための自動チェックかをよく考えて
  • やるとしても小さいステップで細かくそして継続的にやる

というメッセージを強く受け取りました。特に明確にするためにDSLやカスタムアサーションを利用する、というポイントはとても感動&興奮しました。 普段意識していることではあるのですが、意図を明確にするためにもっとできることは沢山ある!という気づきがあったので、そこに飽くなきクラフトマンシップを燃やしていきたいと思った次第です。

12日のエントリー

遅くなってしまいすみませんでした。 12日のエントリーはakito0107さんのターン! よろしくお願いします。

*1:I hereby give Yotaro Takahashi the right to use the code sample from my Agile Singapore 2016 presentation on Unit Test Craftsmanship in a blog post as long as the original author and source are cited.

*2:通称「鈍器」と呼ばれています。

変化を楽しむ

はじめに

これは【その2】妻・夫を愛してるITエンジニア Advent Calendar 2016 の6日目の記事です。 前日はknt_mrさんの妻を愛してる IT エンジニアの件です。ラブラブさが伝わってきてほっこりしました。

一応今日が入籍してから6年半というのにかこつけて、徒然なるままに書きます。

嫁と私

私はエンジニアで、嫁は企業法務をやってます。 何と私法学部出身で、嫁とは大学時代のゼミで知り合いました。

もともと法学部だったもので、最初は家に友人を招いた時は、「け、ケンカしないで」とよく言われました。 本人たちからすると、「自分の想定している文脈はこうなので、その意見は当たらないと思う」とか「それはこうなんじゃないの??」 と言った会話は比較的日常だったので、ケンカしているように見えるのは驚きでした。 「今日もケンカしないでって言われちゃったね。。。」と夜反省会みたいになるのは結婚直後くらいの良い思い出です。

夫婦も変化していく

さて、そんな我々夫婦ですが、結婚直後から、今ではだいぶ付き合い方も変わってきたかなと思います。 最初は妥協みたいなものを許さず、お互い高みを目指す感じでしたが、 子どもができてワークライフバランスを二人で見直して、家庭と仕事のいいバランスを模索したり、 それとは別に私は計3回の転職をしたり。

最近だと、家の会話にSlackを導入したり、帰りの買い物リストをTrelloで管理してみたり。 (蛇足ですが、Slackは #children チャンネルを作ってるのですが、熱を出した時に様子を書いたりしていると結構重宝します)

法学部、法務というと硬いイメージがあるかもですが、嫁はその辺とても柔軟だし新しい物好き?なので、 いろいろな新しいことにチャレンジできます。

あと意外に自動化が好きで、結婚直後から食洗機と乾燥機能付き洗濯機とルンバは抑えました。 こう見てみると意外とエンジニアぽいですね。

私の方は私の方で、嫁が買う企業法務本を夜な夜な読んだりするのは結構楽しいので、良い気分転換になっていたりします。 総じて法務の本は内容や文調がお堅いですが。

変化を楽しむ

そんな中で、夫婦として今は変化を楽しめていると思っています。 でも改めて考えると、それってとても素敵なことですよね。

これからも夫婦でいろんなことにチャレンジして、新しい世界を一緒に見られたらいいなと思っています。 嫁氏、これからもよろしくです。

シンガポールに来ています

タイトルのまんまですが。

出張でこれに参加するためです。
Agile Singapore Conference 2016, 6-7 Oct

タイムスケジュールを見るとワクワクドキドキな感じなので、楽しんできたいと思います。
Agile Singapore 2016 Conference Program Schedule - ConfEngine - Powering Conferences

しかし、さすがこの国は来るたびにデフォルトのクーラーの設定温度が20度で、おもてなしの心がいいですね(寒い)