8/1土曜日に開催された、TDD Boot Camp 2020 Onlineの実況ツイートを後で見れるようにまとめておく。
↓アーカイブ
https://www.youtube.com/watch?v=Q-FJ3XmFlT8
TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
始まるぞー！#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
「イメージ先行」分かる。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
俺もよく分かってない。#tddbc
分かってるようで分かってない。
「動作するきれいなコード」
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
常にそこにゴールを置いて開発したいよね。#tddbc
テスト容易性が高いものから倒していく。#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
利用者側の観点からテストコードを書く。#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
「成功しているテストが成功しているままで」
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
判断基準が0か1というはっきりしたいものになる。#tddbc
リファクタリングの止め時
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
・決めた時間が来たら(5分から10分とか)
・重複を除去できたら#tddbc
コメントにある「テスト自体のリファクタリングが怖い」問題
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
そこまで経験のない自分でもよく分かる。#tddbc
テストが壊れる怖さ……。
「常にグリーン」を守る
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
グリーンを維持するテクニックみたいのものがある。
↑に対する回答。
問題を分割統治する技術欲しい。#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
レガシーコード改善ガイドに言及あり。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
TODOリストの作り方がすでに綺麗。#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
普段はここまではっきりとしていないなぁ。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
ふんわりはしてるけど。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
テスト名を日本語で書くのはやってる。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
その方が一覧で見たときに何をやってるのか分かりやすい。
ただし、長くなりすぎないように気をつけないといけない。
(たぶん、どこかで間違えてる)#tddbc
「検証→実行→準備の順でコードを書いていく」
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
結果が見えているのだから書けるはず！
のと、そのテストの目的を忘れないためか。
「結局なんだったっけ？」ってなったことある……。#tddbc
今のところ、正常系、異常系でクラスを分けて、テスト名に「正常」「異常」を書かないようにするなど、クラス分けで対応している。(これはこれで面倒なんだけど)
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
Equalsメソッドの引数確認は大事！！
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
C#しか触っていないのにたまに「どっちだっけ？」ってなるので、気をつけないと……。#tddbc
使いやすいコード > 作りやすいコード#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
「作る前に使う」
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
ソフトウェアだからこそできるので、意識していこう。#tddbc
ひどい茶番ｗｗ#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
詳しくは動画でｗ
ミューテーションテスティング
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
初めて聞いた！
調べよう。#tddbc
ひどい茶番の目的
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
「テストコードのテストという厄介者を片付ける」#tddbc
テストに失敗した時にデバッグしないといけなくなるので、asertEqualsを並べるのはアンチパターン。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
「アサーションルーレット」
oh...複数のプロパティを検証したくて、並べまくってた。#tddbc
SI系ならテストコードないところも多い気がする。(あくまで観測範囲の問題かもしれないけど)
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
自分はバリデーションチェックの自動化したくてSelenium導入をさせたところからスタートしてるけど。#tddbc
かといって、別メソッドで1つ1つ検証すると重複問題が発生する。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
重複を片付けるのはある程度決めでやる。
スリーアウト派でいこう。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
重複いくつで共通化？
同時に検証しないといけない場合は、アサーションを増やしても良いが、基本的には疑う。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
重めのテストの場合は、複数アサーションでも可。
基本的にはテストメソッドを増やす。#tddbc
同時に実行したら、必ずエラーになるのはどっかで依存していたからか。(たぶんそうだろうと思って、個別でテスト動かしていたけど(ダメパターン))#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
「順番が固定だと悪用しだす」すこ。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
テスト実行順はランダムって話。
順固定実行の場合、A→B→Cの順じゃないと通らないテストを書きだす。
テストはどこでもいつでも通ることが重要。
仮実装→三角測量→実装
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
仮実装→実装
明白な実装#tddbc
テストコードに仕様が書かれていない問題への対応。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
1.仕様のツリー構造で表現する。
2.インナークラスを使用する。#tddbc
つまり、TODOリスト超大事。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
きれいなTODOリストはそのままテストコードのリストになる。
テストコードがきれいなドキュメントに！！#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
DisplayNameってC#でもあるのかな？#tddbc
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
xUnit.net使えば使える。
三角測量系はのちに消しておく。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
必要最小限のテスト構成にする。
書いた本人だけが消すことができるので、不要なテストコードはきちんと消しておく。#tddbc
テストの構造化とリファクタリングは書きての責任で行う。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
でないと、不良資産になる。#tddbc
非常に勉強になりました。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
ありがとうございました。#tddbc
朝からいいもの見れたなぁ。
— ぺやんぐ🐁 (@peyangu485) 2020年8月1日
何気に誰かからTDDについてきちんと聞いたことなくて、独学のみだったわ……。
ツイートにもある通り、非常に勉強になった。
会社で導入する際はこの動画を見てもらうか、この記事見せるかやな。
