新機能および新端末追加のお知らせ | Remote TestKit
2013/11/28 新機能および新端末追加のお知らせ 2013年11月28日（木）実施のシステムメンテナンスが終了いたしましたのでご報告いたします。 尚、メンテナンス完了に伴い新規機種・機能を追加いたしました。 下記のとおり 1. Android 4.4に対応 Remote TestKitがAndroid 4.4（KitKat）に対応しました。 あわせてレンタルできる端末にNexus 5を追加いたしました。 ２．新規機能追加 自動キャプチャ ファーストビュー機能 「複数端末同時操作」による画像保存時にページ全画面のキャプチャに加え、端末ディスプレイに最初に表示される画面を同時に保存する機能を追加いたしました。 本機能によりレンタルした端末でWebページの確認をする際に1画面に表示される範囲がひと目で確認できるようになりました。 ３．レンタル端末の新規追加 最新端末の追加 ご要望にお答えし
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
テスト駆動JavaScriptの第2章をメモ - あおうさ＠日記
Node塾 講義その６に行くのでメモった Node塾で下記の読書会をする。 テスト駆動JavaScript 作者: Christian Johansen,長尾高弘出版社/メーカー: アスキー・メディアワークス発売日: 2011/11/25メディア: 大型本購入: 19人 クリック: 331回この商品を含むブログを見る Node塾 http://partake.in/events/5890aef3-7449-4ccb-a059-68faf9ce3af1 以下は第2章を抜粋したメモ。これを読んで頂ければわかるがテスト駆動JavaScriptはJavaScriptでTDDをするにはどうすればいいかだけに答えるものではなく、TDD未経験者でもTDDとは何なのか？どうやってTDDを身に付けるのかを記載した本になっている。興味があれば買うといいよ。そしてNode塾に参加すればいいと思いますよ。 第２章
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
TDDや自動化について色々話した
Kenichiro Ota @oota_ken 井芹さんも書いていたようになぜ日本にはテスト自動化スペシャリストがここまで少ないのか。いや、開発者がやっちゃうのかとどっかで議論したい。デブサミ後の囲む会できょんさんとかなあ。 2012-02-02 00:06:02 みかまま @mikantsuki @oota_ken 毎年、新しく入ってきた卒論生に自動テスト環境の構築をさせてみると、しみじみ大変そうだなぁと実感できます。基礎知識がないとけっこうはまるみたいねぇ 2012-02-02 00:16:28
私が考えるTDD 〜TDDは天才にしかできないのか〜 - What is it, naokirin?
TDD Advent Calendarに参加していないのに書くのも微妙なのですが、今回はTDDについてです。 TDD Advent Calendarの記事はかなりハイスペックな内容になっています。今回の私の記事はそれらには到底及ばないと思いますが、私の考えるTDDを書いて行こうと思います。 そもそもTDDとは 『TDDとはアジャイル方法論のエクストリーム・プログラミング（XP）のプラクティスの1つです。』 と言う話を聞きますがXPについてWebで調べてみると、「テスト駆動開発(TDD)」と書かれている場合と、「テストファースト」としか書かれていない場合の2種類の場合が存在します。 おそらく元々、「(Unit) Test First」と「Refactor」という2つのプラクティスがXPには存在していて、それがTDDというXP互換なプラクティスになって言ったのではないかと思います。 さらにTD
なぜ、個人のサービスなのにテストを書くのか。 « blog.udzura.jp
以下のエントリは、自分内ブレインストーミングの結果を書き起こしただけのモノなので、数年後どころか数ヶ月後でも意見が変わっているかもしれない。と言う前提で。 三つ、考えられる。 「未来の自分」が楽になる 自動テストコードは、その状態でのそのソフトウェアの挙動、仕様のスナップショットを撮る、と言う側面があり、それはドキュメントを各行為にも通じるが、「今書いている」自分以外の誰かがそのソフトウェアを変更したり、メンテナンスしたり、理解する際に役に立つ。人間はモノを忘れていく以上、「今書いている」自分以外、とは、当然未来の自分も含まれる。 実際、経験的にも、変更したらまずは rake spec を走らせて、エンバグしていないことを確認できるのは気持ちがすごく楽……。そのサービスを変えつづけていくつもりなら、是非テストを書こう。必ずいいことがある。 で、以下二つは、コードをgithubなどのソーシャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
