mizzsugar’s blog

日々感じていることや学んだことを書きます。エンジニアリング以外にも書くかもしれません。

20181103 ミニTDDBC振り返りその1

都内某所でミニTDDBCみたいなものに参加しました。

今回学んだことは

1. きれいなコミットメッセージの書き方

2. 学習テスト

3. DDDなリファクタリング


この記事では、「1. きれいなコミットメッセージの書き方」について書きます。

今回の題材はこちら

お題: セマンティック・バージョニング · GitHub


我々のGitHub

github.com


1. きれいなコミットメッセージの書き方

問1で最初下記のような仮実装をしていました。

import unittest


class SemVer:
    pass
    
    def get_notation(self) -> str:
        return "1.4.2"


class TestSemVer(unittest.TestCase):
    def test_major_minor_patchにそれぞれ142を与えてバージョンオブジェクトを作成(self):
        semver = SemVer(1, 4, 2)
        actual = semver.get_notation()

        expected = "1.4.2"
        self.assertEqual(expected, actual)


if __name__ == "__main__":
    unittest.main()

他の数字でも通るか不安なので、「1.4.2」以外のテストケースを加えました。

    def test_major_minor_patchにそれぞれ230400を与えてバージョンオブジェクトを作成(self):
        self.assertEqual("2.30.400", SemVer(2, 30, 400).get_notation())

テストケースを加えた後、「コミットすっぞ!」ということで、最初下記のようなコミットメッセージを書きました。


「major=2, minor=3, patch=40でSemVerを作るためのテストを追加した」


これに対して、モブメンバーの方から、こんなふうなご指摘が


「コードに書いてること文字に書いてるだけなので、コミットメッセージにする意味ない」


なんと、意味のないコミットメッセージを書いてしまったようです笑


「コミットメッセージは、なぜその変更をしたのか書くもの」


とのこと。

ここで、t-wadaさんの名言を教えてもらいました。

そして、コミットメッセージのリファクタリングが始まりました。

コミットメッセージも仮実装から始めるスタイル?で、

最初とにかく書く→音読する→書いたことを解釈する→コミットメッセージのリファクタリング

という形で実装。


最終的に、

「入力値が異なると通るか不安なので、テストケースを追加した。」

というコミットメッセージになりました!!

これで、パンセン方もニッコリだそうです!!

(2. 学習テスト につづく・・・)