このエントリについて 2種類の要件 性能要件のテスト offline と online offline 性能テストの自動化 A/B テストはすぐにほしい 機能要件のテスト 性能テストのみで十分なのでは？ テストデータ生成 機能テストをいつ作るか まとめ このエントリについて ポエムです。 11/8(火) に開催された Cloudera World Tokyo 2016 に参加しました。 大規模データに対するデータサイエンスの進め方 #CWT2016 (以下、発表 1) データ分析グループの組織編制とその課題 マーケティングにおけるKPI設計の失敗例 ABテストの活用と、機械学習の導入 #CWT2016 (以下、発表 2) その中で上記の2つの発表がとてもいい話でした。 多少絡みのある内容として機械学習を利用するプロダクトのテストについて述べたいとちょっと前から考えていたので、いい機会なので
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechBlogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
5. 前職で実際にあった出来事 マネージャ 今回はテストファーストでやります ぐるぐる はい！ マネージャ なので、実装に入る前に テスト仕様書を完成させます ぐるぐる はい？ マネージャ テスト仕様書は実装開始までに Fix され、以降の変更は認めません ぐるぐる はいぃぃぃぃ？
仕組みとか説明するのも面倒だし、ソースを出すのも手間だし、論より証拠って便利な言葉に乗っかって。 こんなテストがあったとする。ありえないけど。ないけど、まぁあったとする。 @Grab('junit:junit:4.11') import org.junit.* import org.junit.rules.* import org.junit.runner.* import org.junit.runners.model.* class Tests { static { println 'static-initializer' } @ClassRule public static TestRule classRule = {s,d ->{-> println 'ClassRule-before'; s.evaluate(); println 'ClassRule-after' } as S
6. 各モジュールの役割 l サーバー・クライアント l msgpack-rpcサーバー・クライアントとして振る舞る l だいたい⾃自動⽣生成される l ドライバー l ⽣生データ（⽂文書など）を処理理する層 l 特徴抽出、重み付け、学習を結びつける役割 l コア l ベクトルを受け取る⽣生の学習器 l ベクトルを⽣生成する⽣生の特徴抽出器 l 最近リポジトリを分離離した（jubatus_core） 6
機械学習のテスト自動化コトハジメ」発表資料です。 http://connpass.com/event/6275/
論よりコードということでサンプルをつらつらと。 package study.mockito.helloworld; import java.util.ArrayList; import java.util.Iterator; import java.util.LinkedList; import java.util.List; import java.util.java.util.NoSuchElemenit.Assert; import org.junit.Test; import org.mockito.ArgumentCaptor; import org.mockito.InOrder; import org.mockito.Mock; import org.mockito.Mockito; import o
Java Day Tokyo 2014で「Javaアプリケーション開発におけるテストとTDDの実践」というセッションを@t_wadaと@shuji_w6eと@nekopの3人共演でやりました。講演中はいっぱいいっぱいなのであまりまわりの状況がよく見えていなかったのですが、250人の部屋が満席立ち見という状態になっていたみたいです。ありがとうございます。 こんな大規模なイベントを参加費無料かつすばらしい設備の会場でやるというのはとてもすごいことだと思います。OracleさんのJavaに対する姿勢が見えますね。ありがとうございました。 自分は統合テスト自動化というトピックで、より本物に近い環境でテストすることの重要性とか、Arquillianｲｲﾖｰ、統合テストのコスト下げられるよー、楽しいよー、ってお話をしました。スライドは以下のURLで公開しています。 http://nekop.githu
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
第4回 Ques (2014.4.22 開催) でお話する「機械学習分野におけるテストの自動化」の発表資料です。
DevLove関西に行ったので、「課題をテストで解決する」という発表をしてきました。 内容はスライドに書いてあるとおりです。以下のことを特に話したくて、今回の発表をしました。 何度も起こる課題があったときに人が気をつけようとしない 最悪のケースでは根本原因を知ろうとせず、間違えた人を怒ることで解決しようとしてしまう 何度も起こる課題なら、機械に自動的にやらせる その例として今回はテストでやりましょうという話をした あとテストいろいろあって始め方がわからないという時は、こういう課題をテストにするというところから始めるとやりやすいかもしれない 参考 この資料作るにあたってひたすらブログ書いたので参考にどうぞ 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->b
技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの
13. ## Dockerfile の配置 ├──Gemfile dockerfiles/<image-name> で ├──Gemfile.lock Dockerfile を配置する ├──Rakefile ├──dockerfiles │ ├──base │ │ ├──Dockerfile │ │ └──keys │ │ ├──id_rsa │ │ └──id_rsa.pub base イメージ │ └──jenkins │ ├──Dockerfile │ └──start-jenkins.sh └──spec ├──base jenkins イメージ │ └──sshd_spec.rb ├──jenkins │ └──jenkins_spec.rb └──spec_helper.rb 14. ## spec の配置 ├──Gemfile spec/<image-name> で ├──
7. 本日のスケジュール 11:00∼12:15 TDD, ユニットテストに関する講演 12:15∼12:30 ペアプロとお題の説明 12:30∼13:30 ペア作成、昼食、自己紹介など 13:30∼15:00 演習（前半） 15:00∼15:30 レビュー① 15:30∼17:00 演習（前半） 17:00∼17:30 レビュー② 17:30∼17:50 振り返り ※休憩やお手洗いはご自由にお取りください 8. TDD Boot Camp(TDDBC) とは、テスト 駆動開発(Test Driven Development)につ いて、座学だけでなく、実習形式で手を 動かして体得することを目的とするイベ ントです。 http://devtesting.jp/tddbc/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
