モブプロでTDDしてみたっておはなし

# はじめに

[いなたつアドカレ](https://qiita.com/advent-calendar/2019/allinatatsu)の九日目の記事です。

今回は本日行われた[関西でモブプログラミングやってみぃ〜ひん??](https://kmob.connpass.com/event/154259/)に参加した感想や、モブプロってなんだTDDってなんだってのを学んできたお話です。

なお、本記事はモブプロなどの説明がメインで今回実際にしたTDDの実装の話は次の記事のメインの内容となります。

# モブプロって一体なに

モブプロとは、三人以上で一組になり、一つの画面に複数人で向き合いプログラミンングをすると言ったものです。
ここでのモブは、群衆とかそんな意味です。

そして、参加者は「タイピスト」と「モブ」のふたつの役割にわかれ、一定時間を経て、タイピストが順番に入れ替わります。

## タイピストとは

タイピストはドライバと呼ばれたりもします。

タイピストができることは以下の２つです

- モブの指示にしたがって実装する
- モブの指示に対して質問をする

ここで注意して欲しいのはタイピストが自分で実装を考えてプログラムを書くのは **NG** です。
言われた通りにプログラムを書く機械になりましょう。
モブに言われたことがわからなかった場合は素直にモブに質問しましょう。

## モブとは

その他大勢ですね。
モブができることは以下の4つです

- 実装を考える
- わからないことをぐぐる
- タイピストに指示をする
- モブ同士で相談する

プログラムを考え、タイピストに指示をするのが主な役目です。

## TDDってなに
Test Driven Development(テスト駆動開発)の略称でテストコードをベースにし、実装を書いていくプログラミングの方法です。
TDDには3つの状態があります

- Red テストコードの用件を満たしていない状態
- Green テストコードの用件をとりあえず満たしている状態
- Refactoring テストコードの用件を満たした状態を維持しながらプログラムをより綺麗に簡潔に修正する状態

おもにこの三つの状態を順番に繰り返していきます。

### TDDのフロー

1. 課題の定義
2. 課題を適切な粒度に切り分ける
3. 最小のシナリオを満たすテストコードの作成(Red)
4. テストコードが成功するプログラムを実装(Green)
5. 実装したプログラムをより良いプログラムに修正する(Refactoring)
6. シナリオを拡大しそれに伴ったテストコードに修正する(Red)

以降は4,5,6を課題用件を完全に満たすまで繰り返します。

## モブプロのフロー
話はここでモブプロへと戻ります。

1. チーム作成
2. 自己紹介
3. 言語の決定
4. 課題の決定
5. 順番にタイピストを回し、課題を実装する
6. 課題の完了

このような流れでモブプロを行います。

## 実際に行った流れ

フローの通りまずはチーム作成しました。今回は18人の人がいたので、1チーム6人の3チームにわかれました。
各チーム自己紹介などをして、僕が参加していたチームではweb系の人が多かったため、言語はまずはPythonですることにしました(関係ない)
そして、全員がモブプロを初めてするということで、今回はFizzBuzzからやってみることにしました。\
今回エディタとして[cyber-dojo](https://cyber-dojo.org/)というサイトを使用しました。

cyber-dojoを開き、i'm on my own をポチッとし、create a new session をポチッとすると、言語や課題の設定画面に移ります。
僕たちはPython pytestでFizzBuzzを選択しました。

するとこんな画面になります。

![スクリーンショット 2019-12-09 23.37.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269859/6e0b2020-10b4-56ff-01af-9ad234187fe2.png)


readme.txtには実装する仕様が記されています。

```hiker.py
class Hiker:

    def answer(self):
        return 6 * 9

```

```test_hiker.py

import hiker

def test_life_the_universe_and_everything():
    '''a simple example to start you off'''
    douglas = hiker.Hiker()
    assert douglas.answer() == 42

```
それぞれプログラムはこんな感じになっています。

まずはtestボタンを押して初めてのテストを行いましょう。![スクリーンショット 2019-12-09 23.38.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269859/d1c20bd4-ce0b-5775-ddfc-6d5289899b79.png)

42くれっつってるのに54なんか寄越すなよ！っておこられましたね。
しかし、これで、testが走って間違っている箇所を示してくれることがわかりました。

では54ではなく42を返すように6 * 9 を　6 * 7 に変更します。

```hiker.py

class Hiker:

    def answer(self):
        return 6 * 7

```
そしてもう一度testボタンを押しましょう。

![スクリーンショット 2019-12-09 23.41.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269859/cf9215aa-62d1-51d2-e04e-732d817427da.png)

これで、ようやく第一のテストをクリアしました。

では次の記事で、pytestを使ったFizzBuzzをしていきます。

# モブプロの感想

- 複数人で一つの画面をみてプログラムを書くと言った経験を初めてしたため、とても新鮮な感覚で楽しかった
- 自分が気がつかなかったアプローチが出てきたりするのが、面白かった
- TDDも初経験だったので、まずはテストケースを書くというのが、実装わかるのに〜！と少しもどかしかったですが、これが、コードの品質を守るということなんだなと感じた
- タイピストをしているときに、指示をしっかり聞いて、プログラムに反映するのは少し難しかった
- モブをしているときは、頭に浮かんだ実装を的確にタイピストに伝えるのは普段と違う頭を使った
- 一人でプログラムをするのとは違った面白さ、難しさがあり、とても充実した時間だった。
- 複数人で協力しているからか、テストが通ったとき、完成した時の達成感が大きい
- テストの結果はわかってるけど、「だめだー」とか、「いけたー！」とかいいながら都度テストを実行するのがとても楽しい
# まとめ
一味違った頭の使い方をしたり、複数人で協力してプログラムをつくるのはとても楽しい。みんなモブプロやろう。
次回はpytestでfizzbuzzした時にどんな感じで進めて言ったかを事実ベースで書いていきま〜す