TWBMT

技術的な記事や覚書について書いていきます。その内、自作サイトとかに技術記事をまとめたい。

ソフトウェアデザイン 2022年3月号の「そろそろはじめるテスト駆動開発」を読んでみた。

ポッドキャストを聴き、そのままの勢いで Software Design 2022年3月号 を購入し、読んでみました。

第1章はポッドキャスト t_wada さんのブログにもある通り、
「自動テスト・テストファーストテスト駆動開発」x「利点・注意点」
の6象限についてまとめてある非常に内容のギュッと詰まった記事でした。

第2,3章にはJest を用いた環境構築・TDDの手法などがまとめられておりました。 テストの種類・考え方・現場で実践する為のコツについても触れられていて、こちらも濃密。 (Jest 書きたい。。)

今、自分にとって「やりたいこと、興味あること、必要なこと」が自動テストの領域だったので、より詳しく言語化出来て良かったなぁと思いました。
総じて、非常に学びが多かったので、買って良かったなぁと思いました。

感想・気づき・学んだこと

雑誌本編の話や具体的な知識には触れないので、雑誌やポッドキャストを是非聴いてみてください。
無料公開のポッドキャストの内容の範囲での個人的な気づきの一部だけ。

自動テスト・テストファースト・TDD にまつわる認識のズレ
t_wada さんが執筆動機にもあげているそれぞれの言葉の定義について。

実際に僕も人と話す時に認識がズレてたことがあったので、しっかり言葉の意味を揃えられた方が良いなぁ。

ちなみに、個人的にTDDは「コード書く前にはちゃんと設計や仕様を考えた方が良いよね」ということを体感できるから凄く良いと思ってます。
テストを書くに限らず、それがしっかり出来ている時はPRが通るし、それがしっかり出来ていない時はPRが通らない。

テストとソフトウェアの変更容易性について
ポッドキャストで登場する「Testing」「Cheking」っていう概念は、ソフトウェア開発に自動テストが必須な理由を言語化する為に必要な言葉だなぁと思いましたね。

後、これはどちらかというとDDDの文脈からの気付きなのですが、
理想的に言えば最初から「変わらない重要な処理」を見つけモジュール化して、「常に検証可能な状態」に置くことが出来れば良いのかなぁと。
ドメインモデリングはそういった状態を目指す為の設計手法という解釈ですね。

自動テストの質について
より質の高い自動テストを回そうとするとチームの問題に発展する、と思い至りましたね。 知り合いが、設計の話がチームビルディングの話になり、チームビルディングの話が組織論の話になる、言っていたけど、ここが入り口なのかと。。笑

他にも様々学びや知識・気づきがありましたね。

知らなかった語彙

まとめ

ラーメン食べながらポッドキャスト聴いたのが購入のキッカケだったので、ラーメンを食べて良かったなぁと思いました。
これからもこまめにラーメンを食べたいと思います。

それはそれとして、
以前参加した TDDBC に参加して TDD に触れたことが自分のコードが良くなるキッカケ、コードへの悩みを解決するヒントが得られた機会でした。 なので、同じ様に悩んでいる人は是非、TDD に触れてみてくれたら良いなぁと思います。