should i test private methods?
should i test private methods?
はじめに こんにちは、久しぶりに技術系の記事を書きます、株式会社カンムで機械学習エンジニアをしている fkubota です。 今日はSQLについてです。 弊社に入社してから毎日のようにSQLのクエリを書いてきました。 クエリを書き始めてからもう3年が経とうとしています。 日々クエリを書きながら少しずつ自分のスタイルが出来上がってきているのを日々実感しています。 僕は 正確で 読みやすく 再利用しやすいクエリを 高速に 生み出すための工夫を重ねてきました。 結果的にテスト駆動開発ぽいスタイルが生まれたので今日は紹介してみようと思います。 似たような記事がないので少しドキドキですが温かい気持ちで読んでもらえると嬉しいです。 対象読者 対象読者は、分析のためにクエリを書いている人とします。 プロダクトに乗せるクエリというより、ビジネス的になにか示唆を得たいときにクエリを書く人を想定します。 痛み
新卒向け研修資料「テスト文字列に”うんこ”と入れるな」を公開しました 代表の松井です。 弊社インフィニットループでは、近年「新卒ファースト」を合言葉に社内教育に力を入れています。 先日、主に新卒向け(それ以外の参加者も多くいましたが)に、「テスト文字列に”うんこ”と入れるな」という講義を行いましたので、その資料を公開します。 なぜ人は入力欄に「うんこ」と入れてしまうのでしょうか。 それはどういう経路で社外に漏れ、防ぐには何をすべきなのでしょうか。 タイトルはアレですが、内容は至って真面目に書いています。 悲しい事故を防ぐために「仕事中にはふざけないこと」など、新社会人に必要なメッセージを強く込めたつもりですので、ぜひ本資料をあなたの会社での研修にも役立てていただければと思います。 ツイート
こんにちは。 2回にわたってGolang標準の testing パッケージを使ったユニットテストについてお伝えしてきました。 testingパッケージを使ったユニットテスト(testing) テストにおける共通処理(testing) アプリケーションのテスト(gomock, httptest) 今回はGolangで作成したアプリケーションをテストする際に利用できるライブラリなどについて紹介します。 この文章中に登場するサンプルは GitHub にありますので、実際に動作させることが可能です。 $ go get github.com/duck8823/sample-go-testing $ cd $GOPATH/src/github.com/duck8823/sample-go-testing $ git checkout refs/tags/blog $ dep ensure # 依存パッ
最近何度か聞かれたので自分がGolangでCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単に書いておく.まずはinterfaceを使ったテストの基本について説明し次に自分が実践している簡単なテクニックをいくつか紹介する. なおGolangのテストの基本については @suzuken さんによる「みんなのGo言語」 の6章が最高なので今すぐ買ってくれ! 前提 自分はテストフレームワークや外部ツールは全く使わない.標準のtestingパッケージのみを使う.https://golang.org/doc/faq#Packages_Testing にも書かれているようにテストのためのフレームワークを使うことは新たなMini language(DSL)を導入することと変わらない.最初にそれを書く人は楽になるかもしれないが新しくプロジェクトに参入してきたひ
Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開 Container Structure Testは、コンテナ内部でコマンドを実行することで正しい出力やエラーが帰ってくるかどうかや、コンテナ内部のファイルが正しく格納されているかなどの検証を実行できるフレームワークです。 具体的には下記のテストをサポートしていると説明されています。 Command Tests コンテナイメージ内部でコマンドを実行し、正しい出力やエラーが返ってくるかを検証する。 File Existence Tests コンテナイメージ内部に、あるファイルがファイルシステム内の適切な位置に存在しているかどうかを検証する。 File Content Tests コンテナイメージ内のファイルシステムにあるファイルのコンテンツとメタデータ
この記事は、Go2 Advent Calendar 2017の15日目の記事です。 最初に Go言語のHTTPサーバに対してテストを実装する方法を簡単にですがご紹介したいと思います。 今回はサーバ側の実装としてechoを利用していますが、他のフレームワークを利用していても同様にテストすることが可能です。 今回のテスト対象のHTTPサーバは以下の通りです。 package main import ( "net/http" "github.com/labstack/echo" ) const helloMessage = "Hello, World!" func main() { router := NewRouter() router.Start(":8080") } func NewRouter() *echo.Echo { e := echo.New() e.GET("/hello",
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです!しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
とsongmuさんに教えてもらったことを参考に考えてやってみた方法を紹介します。あくまでも自分が考えた方法です。もっといい方法などあればぜひ教えてください。 まずテストの実行前に常に実行する処理を書きたいです。これは*testing.Mを使えばできます。 こう書くことでテストの実行前に setup 関数、全てのテスト終了時に clean 関数を実行できます。tmpのディレクトリ名を渡しているのはあとで解説します。それでは setup 関数と clean 関数はどうすればいいのかという話になりますが、その前にどういうテストを実行すべきかを考えてみます。 今回は外部プログラムの代わりに違うプログラムを実行したいのでそのプログラムを setup 関数で準備します。準備するプログラムは以下のようにしました。 起動したプロセスが突然死んだり、SIGTERMを送ってもなかなか死なないケースのパターンを
JAWS Festa 東海道 2016
クラウドのリージョンを丸ごと落とす過酷な試験を実現する「Chaos Kong」、Netflixが発表。「カオスエンジニアリング」の指針も表明 動画配信サービスのNetflixが、Amazonクラウド上のサーバをランダムに落とすことでシステムの堅牢性をチェックするという画期的な考え方のツール「Chaos Monkey」を発表したのは2012年でした。 サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 Netflixは普段からChaos Monekeyでシステムをテストし続けていたおかげで、昨年10月にAmazon EC2の全インスタンスの約10%がリブートされるという大規模メンテナンスも難なく乗り切ることができたと報告しています。 そしてこのChaos Monkeyの成功に基づき、さらに過酷な状況をシミュレ
AWSのリソース構成をServerspecのようにテストできる "awspec" をつくりました。 github.com 例えばEC2インスタンスであれば、以下のように書けます。 describe ec2('my-ec2') do it { should exist } it { should be_running } it { should_not be_stopped } its(:instance_id) { should eq 'i-ec12345a' } its(:private_ip_address) { should eq '10.0.1.1' } it { should have_security_group('my-security-group-name') } it { should belong_to_vpc('my-vpc') } it { should belon
少し前までiOSとかAndroidのネイティブアプリとかゲームアプリとかしか開発してなくて、テスト真面目に書いたことが無かった。 テスト真面目に書いたこと無くても、テスト書いたほうが良いとは思っていて、MockとかStubとかテストデータの生成と破棄とかを考えると安い受託開発で納期も少ないしディレクターとかに手動テスト任せたほうがコスト低いよねみたいな感じだった。あとは身近にスマホアプリのテストをしっかりと書いてきた人が居なかったのもテスト真面目に書いてなかった一因ではあると思う。 この前までcocos2d-xでゲームを開発してて、最初はtemplate使って頑張ってDIみたいなことしてみたりしたけど、めちゃくちゃコスト高いし、C++製でandroid-nkdで問題なくビルド出来る良さそうなMockとかStubとかDIとか出来るライブラリが無くて結局通信とかデータとかが絡まない部分のテスト
久しぶりにちゃんとgolangを勉強していこうという事で、ログを残します。 今日のテーマ testingパッケージを使ってテストを書いてみる gomでgospelをインストール gospelでテスト書いてみる 独自matcherを書いてみる 環境 MacOSX 10.9.4 go 1.3 brewでインストール 構成 $ tree . . ├── Gomfile ├── src │ └── model │ ├── user.go │ ├── user_gospel_test.go │ └── user_test.go └── vendor testingパッケージを使ってテストを書いてみる まずは、標準のお作法にしたがってテストを書いてみます。 テスト対象はこんな感じです。 user.go package model import ( "strings" ) type Us
FactoryGirl というテストデータを用意するためのgemがあります。 読んだ人に、どんなデータが入ることを想定しているか、それが伝わるデータを用意していきたいですね。'MyString'じゃなくて、例えばどんなデータなのかを教えて欲しいのです。 伝わりづらい例 FactoryGirl.define do factory :post do title "MyString" content "MyString" end end 具体的な例 FactoryGirl.define do factory :post do title "pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション" content "pplogの過去のポエムを複数単語で絞込できるようになりました。" end end FactoryGirl.define do factor
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか?もしくはコードカバレッジだけにとらわれすぎていないでしょうか? 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか?ざっくり説明すると次の通りです。 RubyU
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く