コマンドラインツールを作るときに考えているちょっとした設計方針 | おそらくはそれさえも平凡な日々
個人的にPerlでもGoでもRubyでもコマンドラインツールを作るときに考えることの一つに以下がある。 その実装言語からライブラリとして直接呼べるインターフェースを作り、コマンドもそれを呼び出すようにする。 どういうことかというと、最近書いたgo-timeoutの場合、 % go-timeout --kill-after 5 --signal=HUP 10 perl -E "say 'Hello'" は、内部的に以下を呼び出している。 tio := &timeout.Timeout{ Cmd: exec.Command("perl", "-E", "say 'Hello'"), Duration: 10 * time.Second, KillAfter: 5 * time.Second, Signal: syscall.SIGHUP, } exitStatus := tio.RunSimp
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
