Goで書くテスタブルなCLIツールの作り方 | gihyo.jp
CLIツールをテストする難しさ ターミナルなどで動作するCLI（コマンドラインインタフェース）ツールは、パッケージを公開して利用してもらうライブラリと比べてテストがしにくいと感じる読者も多いでしょう。 CLIツールは、ファイル/標準入力からの入力や、ファイル/標準出力/標準エラー出力への出力があることが多いです。また、コマンドライン引数やオプション（フラグ）によって変わる挙動のパターンが多いため、網羅的なテストが大変です。 入出力についても単一のファイルを読み書きするだけではなく、ディレクトリごと作成したり、特定のディレクトリ以下を再帰的に読み込むような処理もよくあります。 main関数にすべての処理をすべて書くような作りのCLIツールだと、実際にビルドしてテストスクリプトなどから動かしてテストするしかありません。しかし、せっかくCLIツールをGoで書いているのであれば、テストもGoで書き
決済チームがテストコードを書く際に気を付けていること - UPSIDER Techblog
こんにちは。決済チームでエンジニアとして働いている芦川です。 UPSIDER Tech blog 第2弾として「決済チームがテストコードを書く際に気をつけていること」を紹介しようと思います。 TL;DR 100％のテストカバレッジを目指す テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき 私たちは日々大量のコードを書いており、そのシチュエーションは多岐にわたります。 そういった環境において、動作確認からのコード改修のコストを考えた場合、自動テストの有無によって生産性に大きく差が出ることは容易に想像ができます。また、既存のサービスに改修を加えるために、そのサービスの概要を把握したい場合、良いテストコードはドキュメントとして役立ちます。 以前、私はテストコードを一切書かないプロダクトの開
Go公式のlinter、Golintが非推奨になった
Goが公式で出していたGolintがdeprecated/frozenしました。 メンテがされていない 2018年から実質的な変更が加わってない Issueも放置されているものが多い golang orgに存在するlinterなのでGoが公式として推奨しているlinterに見える Go が実際には保守されていないプログラムを公式として推奨しているように見えてしまう 開発者は合理的に異なるスタイルを採用したい場合がある Golint単体で特定の警告を無視したりするなどの機能を持っていない ということからattractive nuisance（魅力的な迷惑者）になっているというProposalでした。 Issueの議論を見てもdeprecate/frozenすることに対して否定的な意見は少なく、一年ほど前にapproveされました。(なので「非推奨にしよう」なったの自体は少し前の話です) そし
Big Sky :: Go に Fuzz testing が入った。
みなさん Fuzz testing ってご存じでしょうか。 人間が作る物は必ずといっていいほどバグが存在します。そしてそのコードをテストする人間も必ずバグを見逃します。 想定していなかった境界値テスト等、人間には先入観という物があり、それが邪魔をして簡単にバグを見逃します。昨今、この様な誰も気付かなかったバグの隙間を突く様な脆弱性が沢山見つかっています。 物によっては重大インシデントに発展する物まであります。 こういった人間では想定できない様なバグを見付けてくれるのが Fuzz testing です。Fuzz testing を実施する事で、ソフトウェアは頑丈になり安全にもなりえます。 本日、Go の master ブランチに Fuzz testing の機能が入りました。 [dev.fuzz] Merge remote-tracking branch 'origin/dev.fuzz'
データベースへの接続を伴うGoの並列テスト | Money Forward Kessai TECH BLOG
こんにちは、MF KESSAIでバックエンドのエンジニアのgarsueです。 2019年もあっという間すぎて戦慄しています。 今回はMF KESSAIでのGoのテストについて、ちょっと工夫してる点を書いてみようと思います。 並列テストによる問題 Go標準のテスト実行コマンドgo testはデフォルトでパッケージごとにテストを並列実行します。 通常は何もしなくてもテストが並列実行されてうれしいのですが、たまに困るケースがあります。 ファイルやDBなどの外部のリソースを触るテストが並列実行されて競合してしまうケースです。 MF KESSAIでは、テスト用のMySQLに接続して実際に読み書きを行うテストを多数書いています。 それらが並列実行されることで、各テストのテストデータ同士が競合してしまうという問題がありました。 開発初期はとりあえずgo test -p 1として並列実行を諦め、問題を回避
Go言語でのテストの並列化 〜t.Parallel()メソッドを理解する〜 | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2020 の6日目の記事です。 メルペイでBackendエンジニアをしている柴田（@yoshiki_shibata）です。この記事では、Go言語のtestingパッケージに用意されている並列化の機能について説明します。 Go言語では、テストコードを作成するためのtestingパッケージが用意されています。一般に開発するソフトウェアの規模が大きくなるに従って、作成されるテストコードの量も多くなり、すべてのテストが終了するまでの時間も長くなっていきます。特に、データベースへアクセスするようなテストでは、データベースへの通信時間がテスト時間の多く占めますので、テストコードを逐次実行するよりは並列実行することで、テスト時間を短縮できます（厳密には用語「並行」ですが、t.Parallel()メソッドの説明なので、この記事では用語「並列
Golangにおけるinterfaceをつかったテスト技法 | SOTA
最近何度か聞かれたので自分がGolangでCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単に書いておく．まずはinterfaceを使ったテストの基本について説明し次に自分が実践している簡単なテクニックをいくつか紹介する． なおGolangのテストの基本については @suzuken さんによる「みんなのGo言語」 の6章が最高なので今すぐ買ってくれ！ 前提 自分はテストフレームワークや外部ツールは全く使わない．標準のtestingパッケージのみを使う．https://golang.org/doc/faq#Packages_Testing にも書かれているようにテストのためのフレームワークを使うことは新たなMini language（DSL）を導入することと変わらない．最初にそれを書く人は楽になるかもしれないが新しくプロジェクトに参入してきたひ
Goでテストを書いてみよう
このコードラボでは、時間によってあいさつ文を返す簡単なライブラリを作ります。そして、そのライブラリのテスト書いていくことで、テストのやりかたやテストしやすいGoのコードについて学ぶことができます。 なお、コマンド等はmacOSのコマンドを元に表記してあるため、他のOSの場合には適宜読み替えてください。 まずはGitHubからこのコードラボで使うサンプルコードをダウンロードしましょう。git cloneするか、ZIPでダウンロードして解凍しましょう。 $ git clone https://github.com/golangtokyo/codelab.git ZIPでダウンロード なお、このコードラボのサンプルコードはgo-greeting以下に入っています。 $ cd codelab/go-greeting $ ls 1_helloworld 2_time 3_package 4_mock
テスト駆動開発(本)を Go 言語で取り組んでみる - Qiita
はじめに 先日、t_wada さんが弊社に公演に来てくださいました。 それに触発され、t_wada さんが訳されたテスト駆動開発を、現在学習中の Go 言語で取り組んでみました。 本記事中の引用は、特に断りがない限りこの本の引用になります。 ※第Ⅰ部まで終了 リポジトリ 前提 筆者の Go の習熟度はA Tour of Goを終了したくらいです。 バージョン go version go1.15.6 windows/amd64 テスト方法について 今回は、Go の標準の testing パッケージと、こちらサードパーティのassertパッケージを使用しています。 Go の標準の testing パッケージには、Assert が含まれておらず、推奨もされていません。 理由については、以下の記事が詳しいです。 ただ、今回は testing としてのテストではなく、checking としてのテスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - rakyll/gotest: go test with colors