2016-11-28 18 views
0

一部のコードでは、文字列の長さが2^32より小さいことを確認するテストがあります。しかし、テストのために大きな文字列を生成すると、メモリ不足のエラーでテストプログラムがクラッシュする可能性があるため、テストするのは難しいです。ユニットテストカバレッジはGoで巨大な文字列長を使用していますか?

どのようにして100%テストカバレッジを達成することができますが、そのようなケースをテストするにはどうすれば安全ですか?

+0

私はそれを注意します100%のテストカバレッジを維持しようとするGoプロジェクトのプロジェクトは、それが有用な指標ではないという理由だけではほとんどありません。カバレッジのためだけに存在する無駄なテストや壊れたテストで終わってしまいます。テストを実行するためにコードをリファクタリングしなければならないことがよくあります。 – JimB

+0

同意します。すべてをテストせずに100%カバレッジを作成することも可能です。 – chmike

+0

私は今あなたが意味するものを発見しました。この問題は、標準のlib関数が返すエラーコードをテストするときに表示されます。エラーコードの返却を誘導するのは難しい場合があります。 – chmike

答えて

3

テストは変更することができ、あなたの関数の外側の限界を移動し、あなたのコードをリファクタリング:

var limit = 1 << 32 

var ErrTooLarge = errors.New("String is too large!") 

func Process(s string) error { 
    if len(s) > limit { 
     return ErrTooLarge 
    } 
    // All OK 
    return nil 
} 

テストそれ:

go test -coverを実行
func TestProcess(t *testing.T) { 
    // Save limit and restore it at the end: 
    old := limit 
    defer func() { limit = old }() 

    // Test success 
    if err := Process("123"); err != nil { 
     t.Errorf("Expected success, got: %v", err) 
    } 

    // Test failure (too large string) 
    limit = 5 
    if err := Process("123456"); err != ErrTooLarge { 
     t.Errorf("Expected ErrTooLarge, got: %v", err) 
    } 
} 

PASS 
coverage: 100.0% of statements 
ok  play 0.001s 
+0

優れています。それを考えなかった。私の限界は一定でした。一度それを見たら明らかです。 – chmike

関連する問題