kynefuk / 課題2

[kynefuk]

<課題 2> io.Reader と io.Writer

io.Reader とは

一連のデータ(バイト列)の読み込み処理を抽象化したインターフェース。
読み込まれる対象データとしてバイト型の配列を受け取り、読み込んだバイト数とエラーを戻り値とする。

type Reader interface {
    Read(p []byte) (n int, err error)
}

io.Writer とは

一連のデータ(バイト列)の書き込み処理を抽象化したインターフェース
書き込まれる対象データとしてバイト型の配列を受け取り、書き込んだバイト数とエラーを戻り値とする。

type Writer interface {
    Write(p []byte) (n int, err error)
}

標準パッケージでどのように使われているか

データの入出力を表現する様々なパッケージで io.Reader や io.Writer が実装している。
(標準入力を表すos.Stdin、標準出力を表すos.Stdout、ファイルの入出力を表現するos.Fileや、通信の入出力を表現するnet.Connなど)

io.Reader と io.Writer があることでどういう利点があるのか具体例を挙げて考えてみる

入力処理と出力処理の仕様をインターフェースとして定義しておくことで、様々な入出力処理を統一的に扱うことができ、プログラムの柔軟性が高くなる。
例えば、何らかの読み込み処理を行う関数の引数の型をio.Readerとすることで、io.Readerを実装している型であれば何でも受けることができる。
コマンドラインのの処理内容を出力する標準出力や、エラーを表示する標準エラー出力のフィールドの型として io.Writer を指定することで、テスト時に、bytes.Bufferなどに切り替えることができ、テスト容易性を高めることができる。

type Command struct {
	OutStream, ErrStream io.Writer
}

1回目の課題のテストを作ってみて下さい

テストのしやすさを考えてリファクタリングしてみる

テストしやすいように関数の引数を構造体ではなく、stringやintのようなプリミティブ型を受け取るように修正。

テストのカバレッジを取ってみる

go test -coverprofile=profile github.com/gopherdojo/dojo8/kadai2/kynefuk/...
?       github.com/gopherdojo/dojo8/kadai2/kynefuk      [no test files]
ok      github.com/gopherdojo/dojo8/kadai2/kynefuk/cli  0.398s  coverage: 100.0% of statements
ok      github.com/gopherdojo/dojo8/kadai2/kynefuk/converter    0.686s  coverage: 81.0% of statements
?       github.com/gopherdojo/dojo8/kadai2/kynefuk/helper       [no test files]
ok      github.com/gopherdojo/dojo8/kadai2/kynefuk/walker       0.755s  coverage: 60.0% of statements

テーブル駆動テストを行う

一部のテストをテーブル駆動で書きました。

テストヘルパーを作ってみる

• 大部分のテストで共通となるアサーション失敗時のログ出力をテストヘルパーとして実装
• 画像変換のテストデータ作成処理をテストヘルパーに実装