テスト駆動開発体験会 2020.5 (JavaScript)に参加しました

コーディングデザインのフロントエンドHTML&CSSデベロッパー森です。

5/29（土曜日）にマークメイザンで開かれたかごべんの「テスト駆動開発体験会 2020.5 (JavaScript)」に参加しました。
講師の @tomo_masakura さんには事前に「前半は大丈夫だろうけど、後半は難しくなるから見学がいいかも…」と伝えられての参加でした。ついていけなくなったときはUIテストの方法を調べてやってみることにしますーと話していたのですが、果たして…。

動機

森はWebサイト制作をしてきているので、アプリやサービスを開発するプログラマではなく、テスト駆動開発にこれまでほとんど触れることはありませんでした。

とはいえ、周りにプログラマは多く、テストなしに開発できないという話をよく聞くので、どういうものか単純に興味を持ったのと、Webサイト制作の仕事にもその考え方を取り入れることができるのか知りたかったのでした。

準備

事前の準備は下記のとおり。

・WiFi が接続できるノートパソコンを必ずご用意ください
・GitLab.com or GitHub のアカウントを取得しておいてください
・指定した開発環境をセットアップしてください
・Node.js 12.7.0 以降
・JetBrains WebStorm (体験版があります)

テスト駆動開発体験会 2020.5 (JavaScript)

どれもすでに準備できていたので問題なしでした。
（講師の @tomo_masakura さんはGitLab&JetBrains製品の思想がとても気に入っておられて、勉強会や専門学校の授業でよく使われるので準備が不要でした。）

スタート

勉強会ではまずテスト駆動開発ってどういうもの？というところからスタートしました。

その答えは「プログラムを書いたらconsole.logで値を見るでしょ、このテストコードを冴えた仕組みでずっと残しながら開発する方法」ということでした。

この時点ではピンときてなかったですが、振り返るとたしかにそこには「冴えた仕組み」がありました。

一日に何回テストコードを実行していると思いますか？

講師からのドキドキ質問タイム。

一日に何回テストコードを実行していると思いますか？

  1. 3, 4回くらい
  2. 10回くらい
  3. 100回くらい
  4. それ以上

…

…

…

答えは「3. 100回くらい」でした。森がサイト制作するときにHTML/CSS/JavaScriptをlintにかけたらそのくらい行くだろうなと思って100回くらいと答えたんですが合っててびっくり。

よく考えたらlintを通すだけなら「テストコードを書く」ってことをしてないので、テスト駆動開発はかなり工数がかかる方法です。

ここで明らかになって、へえ、と思ったんですが、テスト駆動開発は「テストコードを先に書いて、実装コードを書く」。

これは「期末テストの数学で100点を取る」が先にあって、教科書を何度も復習したり、ドリルをいろいろ通ったりして、自分にテストを課しながら「100点を取る」目的達成に近づける、ということ。

プログラムだと何度でもテストできる。
結果は同じで、よりよいコードになるようにどんどんテストする。

仕様変更があってもテストコードがあるから、結果が変わらないことをちゃんと確認しながら開発できる。
なるほどなるほど。

Jestを利用する

自動テスト用のプログラムは Jest というのを使いました。

インストール周りの解説で長くなるのは意図するところではないので割愛。

ぱっと始めてみたい方はQiitaの「5分で始めるJestで快適テスト生活」をやって見られると良いかもです。

テストコードの実行

最初はテストコード用のファイルのみ作ってテストしました。

// describeはテストケースのグルーピング（複数のテストケースをまとめる）
describe('Sample', () => {
  // testはテストケース
  test('Hello', () => {
    // 変数に入れた結果をexpectでテストにかける
    const actual = 1 + 2;
    expect(actual).toEqual(3);
  });
});

1+2は3だよね、ってことをテストしてます。

WebStormのコンソールにテスト成功の結果が出てきます。
toEqual(3)をtoEqual(2)とかに変更するとテスト失敗の結果がでてきます。
なるほど、こういう感じでテストするのか〜と実感。

他のコードも書いてみたあとで、テストの進め方についてポイントの共有がありました。

  • テストケースは1つ書く、実装する、リファクタリングの繰り返し

一気にテストケースを書いて一気に実装というのはやらないそうです。
どこがバグが見つけにくくなるから。
とにかく少しずつ進める。

  • DBや外部APIに頼らないものはテストしやすい
  • DBや外部APIに頼るものは役割を切り離して、テストしやすい部分を中心にテストする

なるべくシンプルになるように進めるのは大事。

ここで前半が終了。うん、ばっちりついていけた！

途中ついていけなくなる

後半はGitLabからソースをクローンして、講師がコードを書きながら学ぶスタイル。

途中、WebStormの便利な機能を使ってリファクタリングをするところで詰まってしまい、ついていけなくなりましたが、講師のサポートで復帰。

ということでその後も少しつっかかりながらも無事最後まで体験を完遂しました。

講師の @tomo_masakura さん、ありがとうございました！とても楽しかったです！

仕様ができればテストコードが書ける

仕様ができればテストコードが書ける。プログラムは少しずつ作る。一気に作らない。

これはひょっとしてWebサイト制作にも応用できる？

サイト制作に応用？

デザイナは全体像を整えてから細かい部分を作ります。テスト駆動開発とは逆。

ただ、Adobe XDやSketchを使ってデザインするとシンボルを使うことになるので、シンボルができたらコーダーにファイルを共有してもらって、少しずつパーツを作り始める。

作ったパーツをUIテストにかけていく。スジのいい作り方にまとめるためにリファクタリングする。

サイトの全体像ができてきたらページを作っていく。

こういうことなのかな（手戻りが大きい進め方かも）。

まとめ

テスト駆動開発そのものはかなり興味深いものでした。体験会の内容は途中から難しくなりましたが、とても面白くて、サイト制作に照らし合わせて考えるいいネタを提供していただいたな、と。

プログラマは小さいものを積み重ねて大きくしていき、デザイナは全体の輪郭を整えてから細かいところを作るということをしているので、ツールの力を借りながら効率化する方法を探っていきたいところです。自分が知らないだけでモダンな開発方法があるはず…！

GUIテストツールを試してみて記事を書きます〜。

2020年6月25日seminar