私は迷いの中にいる

毎日眠気しかない謎の深海魚の一言日記

wacate2020冬の2日目でやっていた「cyber-dojoで始めるプログラミング勉強」が面白かった

あらすじ

wacate2020冬の2日目のモーニングセッションで
cyber-dojoを使ったプログラミング勉強(TDDを体験してみる)を
やっていたのですが、それが結構面白かったので
メモを残しておこうと思います。

私は英語がプー&プログラミングもだいぶ中途半端というひどい状態ですが
テストに関わっていてずっとTDDを見ないふりしているのはよくない気がするので
下記の走り書きを読んで練習したいときにしてみようと思います。

cyber-dojoで始めるプログラミング勉強

・プログラミング勉強は大事だけどつらい

・つらいの中身→プログラミング以外のつらみがいっぱい
環境構築とか環境構築とか環境構築とか

・そんな「プログラミングの勉強以外のつらみにはまらない」方法が知りたい人へ…
→cyber-dojo!!
(プログラミング練習ができるよ
(TDDができるよ
(モブプロもできるよ

・cyber-dojo is 何?
テスト駆動開発(TDD)の練習ができる(数少ない)プログラミング練習サイト

・TDD is 何?
1.最初に失敗するテスト(要件に基づいたテスト)を書く
2.テストが通るようにコードを書く
3.テストが通る状態を保ちつつコードの重複などを排除(いわゆるリファクタリング
以下1に戻ってループ

・TDDは何がうれしいか?
1.次の作業のための受け入れ基準が明確になる!
2.テストが「コードが何をしているか?」の説明になる
3.自動テストを書くことができるコンポーネント状態が保たれる
4.(テストコードを書く)サイクルを細かく回していくと
コードが動かなくなったときに、前にテストが通っていたときの状態に
すぐ戻れる
→(^o^)安心

TDDについて詳しくは本を…参照!
テスト駆動開発
実践テスト駆動開発

テスト駆動開発の勉強には、開発環境の構築と
ユニットテスト環境の構築が必要
(つまりテストコードを書く環境とテストするコードを書く環境?

PCの環境が…汚れていく…

・プログラミング練習サイト少ない

・そこでCyber-dojoを使おう!

***ここから動画で説明****

補足:この動画の説明が楽しかったのですが
通信速度?の関係で接続がラグっていて勿体無かったので動画(ワーク共有資料)を
見られるうちに概要メモしておきます。
動画に合わせて手を動かしてみると分かりやすかったです。

www.cyber-dojo.org

1.
モブプロやりたいなら右の「we're…」
一人で練習するなら左「i'm on my…」を押す
・今回は一人で練習

2.次の画面で
上:create a new…:新しい環境を作りますか
下:enter an existing…:昔の環境を引っ張り出しますか
・今回は上を選ぶ

3.次の画面は問題選択(choose a problem)
プログラミング練習のお題を選ぶことができる
自分でも任意の例題を作ったりもできる
・例題を選択or自分で作った例題を使う場合は何も選択せず[next]

4.次の画面は言語とテストフレームワークを選ぼう(choose a langage & test-framework)
ここで言語を選択し[next]

5.環境これでいいですか?の確認がでるので[confirm]

6.IDが振られる。このIDをメモっておく
※中断したときにこの番号を指定してあげると途中から始めることができる。
[enter the exercise]を押して開始

7.環境の説明が表示される
赤:テストは失敗している
黄色:テストは走っていない(コンパイルエラーなど)
緑:テストが全部通ったよ
「×」説明で閉じるともう環境が出来ている(おめでたい!)

Hiker.拡張子:テストされる対象(普通にプログラムを書くためのファイル)
Hiker_Test(またはtest_hiker).拡張子:テストコード(テストを書くためのファイル
[+]で任意のファイルを追加できる

最初は
・Hikerの方に「6*9」が書いてある
・Hiker_Testの方に「42」が書いてある
このままの状態で[test]を押すと(太極図がぐるぐるする)
テストコードの期待結果「42」に対して、プログラムの出力が「54」
なので「失敗してるよ」的なログが出る。
[test]の上あたりに赤い●が出る。
プログラムの方を(6*7)に修正して
[test]を押すと成功したっぽいログが出る。
[test]の上あたりに緑の●が出る。
(この「失敗しているテストを、プログラムを直して通す」が1サイクル)

流れは
1.テストコードを書く(まだプログラムコードは実装しない)
2.テストする→失敗する
3.プログラムコードを実装する
4.テストする→成功する
これを1つの仕様ずつで繰り返していく。
いっぺんに複数の仕様のテストを書かず、あくまで1つ1つやっていく、この1つ1つクリアがTDD

TDDの場合は失敗したテストに基づき「最低限の」コードを実装する
詳しくは書籍でお楽しみください…

→書籍を読みながら上記の最低限説明を読んでFizzBuzzでも
やってみるといいかもしれない!

感想

テスト対象に対して結果を書いてテスト、は以前Pythonの試験に向けて勉強していたときに
ほんの少しやっていたので知っていたのですが
TDDの「テストを先に書く」→「失敗する」→「実装する」→「テストを通す」というのを
具体的に見たのは今回が初めてでした。(不勉強にもほどがある
文で読むのと実際を見るのって結構違うので、こういうことを言っていたのか
という腹落ち感がありました。

どこからとっかかれば良いか分からない、に対して
実際の動作を見てみる、は結構有効なんだなというのと
文だけじゃあまり分かっていなかったというのが自覚できて良かったです。

なので、プログラムに対するトラウマの一つの解消法として
・実際に操作しているところを見せてみる
・あわよくばそれに習って手を動かす
は有効なのかもしれないですね。