コンテキスト認識リーダー
Context-aware Reader
コンテキスト認識リーダー？
まず、
io.Readerの簡単な入門書です。この本の他の章を読んだことがあれば、ファイルを開いたり、JSONをエンコードしたり、その他の一般的なタスクを実行したりしたときに、
io.Readerに出くわすことになります。 something からのデータの読み取りに関する単純な抽象化です。1
type Reader interface {
2
Read(p []byte) (n int, err error)
3
}
Copied!
io.Readerを使用すると、標準ライブラリから多くの再利用を得ることができます。 これは、非常に一般的に使用される抽象化です（対応する io.Writerとともに）コンテキスト認識？
前の章でキャンセルを提供するために「コンテキスト
context」を使用する方法について説明しました。これは、計算コストがかかる可能性のあるタスクを実行していて、それらを停止できるようにしたい場合に特に便利です。io.Readerを使用している場合、速度について保証はありません。1ナノ秒または数百時間かかる場合があります。自分のアプリケーションでこの種のタスクをキャンセルできると便利だと思うかもしれませんが、それはMatとDavidが書いたものです。彼らはこの問題を解決するために2つの単純な抽象化（
context.Contextとio.Reader）を組み合わせました。io.Readerをラップしてキャンセルできるように、いくつかの機能をTDDで試してみましょう。これをテストすることは興味深い挑戦を引き起こします。通常、
io.Readerを使用するときは、通常、他の関数にそれを提供しているので、詳細に気を使う必要はありません。 json.NewDecoderやioutil.ReadAllなど。デモしたいのは、次のようなものです。
"ABCDEF"を持つio.Readerが与えられたとき、途中でキャンセル信号を送っても、読み続けようとすると何も出ないので、"ABC"しか出ません。
インターフェースをもう一度見てみましょう。
1
type Reader interface {
2
Read(p []byte) (n int, err error)
3
}
Copied!
ReaderのReadメソッドは、その内容を、提供する []byteに読み込みます。したがって、すべてを読むのではなく、次のことができます。
- すべてのコンテンツに適合しない固定サイズのバイト配列を提供します
- キャンセル信号を送信します
- 再試行してもう一度読み取ると、0バイトの読み取りエラーが返されます
とりあえず、キャンセルのない「ハッピーパス」テストを書いてみましょう。これは、まだ本番用のコードを記述しなくても問題に慣れることができるようにするためです。
1
func TestContextAwareReader(t *testing.T) {
2
t.Run("lets just see how a normal reader works", func(t *testing.T) {
3
rdr := strings.NewReader("123456")
4
got := make([]byte, 3)
5
_, err := rdr.Read(got)
6
7
if err != nil {
8
t.Fatal(err)
9
}
10
11
assertBufferHas(t, got, "123")
12
13
_, err = rdr.Read(got)
14
15
if err != nil {
16
t.Fatal(err)
17
}
18
19
assertBufferHas(t, got, "456")
20
})
21
}
22
23
func assertBufferHas(t *testing.T, buf []byte, want string) {
24
t.Helper()
25
got := string(buf)
26
if got != want {
27
t.Errorf("got %q, want %q", got, want)
28
}
29
}
Copied!
- いくつかのデータを含む文字列から
io.Readerを作成します - 読み込む内容がリーダーの内容よりも小さいバイト配列
- 呼び出しを読んで、内容を確認し、繰り返します
これから、2回目の読み取りの前に動作を変更するために何らかのキャンセル信号を送信することを想像できます。
それがどのように機能するかを見てきましたので、残りの機能をTDDします。
最初にテストを書く
io.Readerをcontext.Contextで作成できるようにしたいと考えています。TDDでは、希望するAPIを想像することから始めて、そのためのテストを作成するのが最善です。
そこから、コンパイラーと失敗したテスト出力で解決策を導きましょう。
1
t.Run("behaves like a normal reader", func(t *testing.T) {
2
rdr := NewCancellableReader(strings.NewReader("123456"))
3
got := make([]byte, 3)
4
_, err := rdr.Read(got)
5
6
if err != nil {
7
t.Fatal(err)
8
}
9
10
assertBufferHas(t, got, "123")
11
12
_, err = rdr.Read(got)
13
14
if err != nil {
15
t.Fatal(err)
16
}
17
18
assertBufferHas(t, got, "456")
19
})
Copied!
テストを実行してみます
1
./cancel_readers_test.go:12:10: undefined: NewCancellableReader
Copied!
テストを実行するための最小限のコードを記述し、失敗したテスト出力を確認します
この関数を定義する必要があり、
io.Readerを返す必要があります1
func NewCancellableReader(rdr io.Reader) io.Reader {
2
return nil
3
}
Copied!
試しに実行してみると
1
=== RUN TestCancelReaders
2
=== RUN TestCancelReaders/behaves_like_a_normal_reader
3
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
4
panic: runtime error: invalid memory address or nil pointer dereference
5
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x10f8fb5]
Copied!
予想通り
成功させるのに十分なコードを書く
今のところ、渡した
io.Readerを返すだけです1
func NewCancellableReader(rdr io.Reader) io.Reader {
2
return rdr
3
}
Copied!
これでテストに成功するはずです。
わかっています、わかっています、これは馬鹿げていて衒学的に見えますが、派手な作業に取り掛かる前に、
io.Readerの「通常の」振る舞いを壊していないかどうかを、ある程度検証することが重要です。最初にテストを書く
次に、キャンセルしてみる必要があります。
1
t.Run("stops reading when cancelled", func(t *testing.T) {
2
ctx, cancel := context.WithCancel(context.Background())
3
rdr := NewCancellableReader(ctx, strings.NewReader("123456"))
4
got := make([]byte, 3)
5
_, err := rdr.Read(got)
6
7
if err != nil {
8
t.Fatal(err)
9
}
10
11
assertBufferHas(t, got, "123")
12
13
cancel()
14
15
n, err := rdr.Read(got)
16
17
if err == nil {
18
t.Error("expected an error after cancellation but didnt get one")
19
}
20
21
if n > 0 {
22
t.Errorf("expected 0 bytes to be read after cancellation but %d were read", n)
23
}
24
})
Copied!
最初のテストは多かれ少なかれコピーできますが、今は次のようになっています。
- 最初の読み取り後に「キャンセル
cancel」できるように、キャンセル付きのcontext.Contextを作成します - コードを機能させるには、関数に
ctxを渡す必要があります - そして、
cancel後に何も読まれなかったことを主張します。
テストを実行してみます
1
./cancel_readers_test.go:33:30: too many arguments in call to NewCancellableReader
2
have (context.Context, *strings.Reader)
3
want (io.Reader)
Copied!
テストを実行するための最小限のコードを記述し、失敗したテスト出力を確認します
コンパイラは何をすべきかを指示しています。コンテキストを受け入れるように署名を更新します。
1
func NewCancellableReader(ctx context.Context, rdr io.Reader) io.Reader {
2
return rdr
3
}
Copied!
（最初のテストが
context.Background を通過するように更新する必要があります。）これで、非常に明確な失敗したテスト出力を見ることができるはずです。
1
=== RUN TestCancelReaders
2
=== RUN TestCancelReaders/stops_reading_when_cancelled
3
--- FAIL: TestCancelReaders (0.00s)
4
--- FAIL: TestCancelReaders/stops_reading_when_cancelled (0.00s)
5
cancel_readers_test.go:48: expected an error but didnt get one
6
cancel_readers_test.go:52: expected 0 bytes to be read after cancellation but 3 were read
Copied!
成功させるのに十分なコードを書く
この時点では、MatとDavidによる元の投稿からコピーして貼り付けていますが、ゆっくりと繰り返し実行します。
読み込んだ
io.Readerとcontext.Contextをカプセル化するタイプが必要であることはわかっているので、それを作成して、元のio.Readerの代わりに関数からそれを返してみましょう1
func NewCancellableReader(ctx context.Context, rdr io.Reader) io.Reader {
2
return &readerCtx{
3
ctx: ctx,
4
delegate: rdr,
5
}
6
}
7
8
type readerCtx struct {
9
ctx context.Context
10
delegate io.Reader
11
}
Copied!
このサイトで何度も強調してきたように、ゆっくりと進み、コンパイラに助けてもらいましょう。
1
./cancel_readers_test.go:60:3: cannot use &readerCtx literal (type *readerCtx) as type io.Reader in return argument:
2
*readerCtx does not implement io.Reader (missing Read method)
Copied!
抽象化はいい感じだけど、必要なインターフェースが実装されてないから、メソッドを追加しよう。
1
func (r *readerCtx) Read(p []byte) (n int, err error) {
2
panic("implement me")
3
}
Copied!
テストを実行すると、それらはコンパイルするはずですが、パニックになります。これはまだ進行中です。
最初のテストを通過させるために、基礎となる
io.Readerへの呼び出しを委任してみましょう。1
func (r readerCtx) Read(p []byte) (n int, err error) {
2
return r.delegate.Read(p)
3
}
Copied!
この時点で、私たちは再び私たちの幸せなパスのテストが合格し、それは私たちのものがきれいに抽象化されているように感じています。
2回目のテストをパスするためには、
context.Contextがキャンセルされたかどうかを確認する必要があります。1
func (r readerCtx) Read(p []byte) (n int, err error) {
2
if err := r.ctx.Err(); err != nil {
3
return 0, err
4
}
5
return r.delegate.Read(p)
6
}
Copied!
これですべてのテストが通過するはずです。エラーを
context.Contextから返していることに気づくでしょう。これにより、コードの呼び出し元がキャンセルが発生した様々な理由を調べることができます。まとめ
- 小さなインターフェイスが良く、構成が簡単
ソフトウェア工学では、デリゲーションパターンはオブジェクト指向の設計パターンであり、オブジェクトを構成して継承と同じコードの再利用を実現することができます。
- この種の作業を始める簡単な方法は、他の部分の動作を変更するために他の部分を合成し始める前に、デリゲートをラップして、デリゲートが通常どのように動作するかを保証するテストを書くことです。これは、目標に向かってコードを書く際に、物事を正しく動作させておくのに役立ちます。
最終更新 3mo ago