Goで書くテスタブルなCLIツールの作り方 | gihyo.jp
CLIツールをテストする難しさ ターミナルなどで動作するCLI（コマンドラインインタフェース）ツールは、パッケージを公開して利用してもらうライブラリと比べてテストがしにくいと感じる読者も多いでしょう。 CLIツールは、ファイル/標準入力からの入力や、ファイル/標準出力/標準エラー出力への出力があることが多いです。また、コマンドライン引数やオプション（フラグ）によって変わる挙動のパターンが多いため、網羅的なテストが大変です。 入出力についても単一のファイルを読み書きするだけではなく、ディレクトリごと作成したり、特定のディレクトリ以下を再帰的に読み込むような処理もよくあります。 main関数にすべての処理をすべて書くような作りのCLIツールだと、実際にビルドしてテストスクリプトなどから動かしてテストするしかありません。しかし、せっかくCLIツールをGoで書いているのであれば、テストもGoで書き
Big Sky :: Go に Fuzz testing が入った。
みなさん Fuzz testing ってご存じでしょうか。 人間が作る物は必ずといっていいほどバグが存在します。そしてそのコードをテストする人間も必ずバグを見逃します。 想定していなかった境界値テスト等、人間には先入観という物があり、それが邪魔をして簡単にバグを見逃します。昨今、この様な誰も気付かなかったバグの隙間を突く様な脆弱性が沢山見つかっています。 物によっては重大インシデントに発展する物まであります。 こういった人間では想定できない様なバグを見付けてくれるのが Fuzz testing です。Fuzz testing を実施する事で、ソフトウェアは頑丈になり安全にもなりえます。 本日、Go の master ブランチに Fuzz testing の機能が入りました。 [dev.fuzz] Merge remote-tracking branch 'origin/dev.fuzz'
Golangにおけるinterfaceをつかったテストで mock を書く技法 - haya14busa
いい記事に感化されて僕も何か書きたくなった。 Golangにおけるinterfaceをつかったテスト技法 | SOTA リスペクト: Big Sky :: golang で終了を確認するテストの書き方 GolangでAPI Clientを実装する | SOTA Big Sky :: GolangでAPI Clientを実装する、の続き 今週のやつではなく先週のです．今週のは特に知見がなかった…grpc-goとか使えたらクライアント勝手に生成されるしいいよねgrpc流行ると便利そう(感想) くらい Golangにおけるinterfaceをつかったテスト技法 | SOTA めっちゃいいなーと思ったんですが，テスト用 の mock を気軽に作るテクニックはあまり詳しく紹介されてなかったのでそのあたりの１つのテクニックを書きたい． 前提 僕もテストフレームワークや外部ツールは全く使わない．標準のt
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - rakyll/gotest: go test with colors
