スターを消すより、まずあれをどうにかすべきでしょ 多数のユーザーが普通のタグをつけている中、一人が罵詈雑言みたいなタグを上限ぎりぎりまで付けることによって、「おすすめタグ」とかがそれで埋め尽くされる 非常に見苦しいというほかない
PHPでテストケースを作成する場合、ネイティブ関数を使っているようなコードに対してテストを実行しようとすると、どうしても環境に依存したり、実リソースにアクセスする必要が出てしまうことがあります。 この記事では、そのような問題に対する対処法を提示します。 経緯みたいなもの 先日もWeb APIをコールするPHPライブラリを書いていたのですが、HTTPをたたく部分のテストを切り離せず、もやもやしていました。 ちょっと前にPerlのTest::Timeというライブラリを教わって感動していたのですが、PHPでもネイティブ関数をオーバーライドできたらどんなにすばらしいだろう、などとぼやいていたのです。 そんなときに、@takimoにPHP 5.3ならオーバーライドできるよねって言われて、ハッと思い立ってテストに組み込む方法を考えてみたところ、割とスマートに実現できそうな方法が見つかったので、方法論の
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか?ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが1つではなく複数の機能をチェックしているか、テストが1つ以上のことをやろう
本日大江戸*1で行われた大江戸Ruby会議01で、高速なテストサイクルを回すにはという内容で発表してきました。 大江戸Ruby会議01 高速なテストサイクルを回すには View more presentations from hotchpotch テストを速くするには二パターンあり、一つは単体実行時の速度・フィードバックの高速化、もう一つはすべてのテスト実行時の高速化があると思っていて、それらについての話です。ぎゅっとまとめると、前半の単体実行時の速度・フィードバック高速化には spork / prefetch-rspec / autotest / watchr を使おうという話と、後半は REE / parallel_tests による高速化・並列実行、remote spec によるリモートマシンでの分散テストについての話です。 特にオレオレプロジェクトの prefetch-rspec
みなさま お久しぶりです。最近フェイスブックアプリを作ったりしてますが、やっぱりテストが大変ですよね>< と思っていたら、今日以下のような API が公開されたみたいです! Test User - グラフAPI - ドキュメンテーション - 開発者向けFacebook アプリをインストールしている、テストユーザーを API で作ってそのユーザーを使ってテストできるようになるんですね! すばらしい! と、いうわけでさっそく試してみた。 まずはアプリの access_token ゲット! まずは、アプリの access_token を取得します。 以下のように POST してください。 $ curl -F grant_type=client_credentials -F client_id=ここにアプリケーションのID -F client_secret=ここにシークレットキー https://
ストーリー by hylom 2010年11月10日 14時47分 バグが何件出るかなんて予測できるの? 部門より ITproにて、「品質管理のやり方として正しいのはどれ? - 今日の腕試し!」なるクイズが掲載されている。品質を上げるの必要なのはバグ出しだけではないが、設問をつくるために敢えてバグ出しをターゲットにしたのだろう。それはいいのだが、個人的にみてこの3択には正解の要素が見受けられない。特に、正解をみてしまうと「今時、こんな方法をとっているベンダーとは疎遠になりたい……」と思ってしまう。 ちなみに、バグ出し(と、そのためのプログラム作り)には開発期間の半分はとるべきだと私は考えているが、そううまくいかないのも現実である。理想と現実に挟まれるSEやプログラマが多いであろうが、諸兄はどこを落とし所にしているのだろうか? ちなみに、私の現職は中小企業のシステム管理である。前職はプログラ
(2008-09-09 19:20 更新: ユーザーパラメーターの設定で繰り返しごとに更新のチェックを入れるようにしました) JMeter でテストをする時に,テストのパラメータを動的に変えたい場合があります.例えば,送出するスレッドごとに宛先を変えるとか,ユーザ名を変えるとか.その方法のメモ. 例えば,変化させたいユーザ一覧を一行に一つ書いた user.txt というテキストファイルを準備する.user1 user2 user3 スレッドグループで右クリックして「追加」→「前処理」→「ユーザーパラメータ」を選択. JMeter内の変数として "user" という名前の変数を定義し,その値を "user.txt" から順次読み込んで利用したい場合,「変数の追加」を押して,「名前」としてパラメータ名 user を,「ユーザー_1」には ${__StringFromFile(user.txt)
テストコード書いてますか? HIROKIです。 murahashiに続いて、テストファーストを導入してみての振り返りをします。 まず、どうやってチームにテストファーストのスタイルを持ち込んだのか。 1.テストが重要だという共通認識を持つ。 前のプロジェクトではテストコードは、ほとんどありませんでした。 その中で、開発になれていない人や新たに人が投入され、 極少数ですが、デグレーションが起きました。 その経験を元にテストが重要だという共通認識を持つことができました。 2.プロジェクト開始時からテストファーストに踏み切る気持ちが必要 テストコードを書かなければコミットさせない。ぐらいの気持ちが必要です。 実際に何度も、本格的な実装が始まる前から口にしていました。 「うちのチームはテストを書かなければコミットを許さない。」と。 3.でも、テストコード書いたことないよ? テストコードを書いたことの
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
勉強 気づけばもう情報処理技術者試験まであと一週間ですね。 以前「一週間で応用情報技術者試験に受かった方法」という記事を書きましたが、今回は応用情報に限らないテストの攻略法を改めて書いてみます。 情報処理技術者試験でも十分に通じると思うので、まだ勉強してないよという去年の僕みたいな人に役立てばなーと思います。 一応、注意事項。テスト直前まで勉強しなかった人向けです。当然、通用しないテストもあります。僕みたいに低レベルな学校じゃないと通じないかもしれません。そもそもテスト勉強せずに点数とれる人には必要ないです。満点を取るのにはあまり向いてないです。まとめ先に問題から始める問題は量より回数確実に点数をとれるところを抑える考えればわかる、まで持っていく徹夜するくらいなら超早起きで勉強テスト中にも諦めない先に問題から始める 予想問題や、練習問題、もし入手できたら過去問から手を付けるのが短時間での
はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く