続・ノハナのテスト自動化
ノハナの中の様子を時に真面目に時にゆるゆるとお伝えします こんにちは、QAエンジニアの武田です。 去年の健康診断で、メタボ予備軍と言われ、キックボクシングを始めたのですが、思うように成果に繋がっていません。。。 もうすぐ今年の健康診断が迫っているので、何かいい減量方法があったら教えて下さい🙇 さて、今日は、前回、テスト自動化の取り組み初期についてご紹介してから約2年が経過した今、どのように運用しているか、その成果など、テスト自動化の現状をお話したいと思います。 Before まず、前回紹介した際の構成がこちらです。 テストは、 Jenkins から 定時点 でリクエストされ、 ローカルPCにつないだ実機 で実行していたのですが、本格的に運用していくには解消すべき大きな課題が2点ほどありました。 1点目は、 環境のメンテナンスが必要 ということです。 テスト実行のリクエストとテスト結果をS
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
EarlGrey - iOS 向けの UI 機能テスト フレームワーク
.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
テストがないJS環境にモダンなテスト環境を導入していく - Qiita
Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr
Can Android apks be tested with UnitTests in Groovy?
I have an Android project and created some new Unit tests and decided to write them in Groovy. For some reason I can’t get Gradle to notice and build them. Is this possible? The directory with the groovy unit tests are included in sourcesets.test.java.srcDirs. If I drop a Java file in that directory it gets noticed and built by Gradle, but the Groovy files are ignored. I know that I can’t use the
Android Unit Tests - no such property: bootClasspath
I'm trying to execute a simple test case for Android following just announced unit testing support - http://tools.android.com/tech-docs/unit-testing-support After carefully following the walkthrough I'm trying to run ./gradlew test. I'm getting this error: Execution failed for task ':app:compileDebugGroovy'. > No such property: bootClasspath for class: com.android.build.gradle.AppPlugin while usin
Test::MockTime - 時間にまつわるtest - Articles Advent Calendar 2011 Test
はい、kawamotoです blogは書いているとはとても言えないぐらいサボっております。 右も左もわからぬひよっこですので奇をてらわずにTest::名前空間のモジュールの紹介をしようと思います。 Test::MockTime は testの最中に実行される time, localtime, gmtime などの時間に関する関数の振る舞いを書き換える便利なモジュールです。 以下のような症状によく効きます。 テストの期待する結果に時刻を入れたいが固定の値を指定できない。 外部のコンポーネントに存在する、時間で変動する要素に依存しないテストを書きたい(たとえば MySQL で時系列のパーティションを使っているなど) テストを実行するたびに経過時間が変動してtestが通ったりこけたりする 使い方はこちらの記事でも説明されていますが、 $ cat ~/test.pl use feature qw(
VOYAGE GROUP エンジニアブログ : iPhoneアプリでABテスト
2014年05月07日18:26 カテゴリiOS iPhoneアプリでABテスト こんにちは、genesixで働くiOSエンジニア、@TachibanaKaoruです。 最近Web業界ではA/Bテストがすっかり定着してきます。 iPhoneアプリでもA/Bテストをしてみたいと思う方も多いと思います。でも、AとBの二種類のパターンでユーザーインターフェースをデザインして、起動時にランダムでどちらかのパターンになるように実装して、アプリをリリースして、ユーザーのレスポンスを計測したあとで、また決まったユーザーインターフェースでアプリをリリースして……なんてことを考えると、ちょっと億劫になってきますよね。 そこで、アプリをリリースし直さずにiPhoneアプリのユーザーインターフェースを動的に変更する方法を実装してみました。ここのユーザーインターフェースはどうしよう、ちょっとユーザーの反応をみて決
ひっそりと、Perl限定TDDBCを行った話 - After Coding
最近、社内の新人研修を企画・運営する仕事をしている。 まだ研修は進行中なので、得られた知見は研修終了予定の6月末以降に書くと思う。 しかし、「とりあえずプログラミングやっとくだろ」と思って考えたTDDBCが結構いい感じっぽいので、そこだけまとめてみようと思う。 TDDBC概要 既に弊社の技術研修で5日間みっちりTDDBCをやってぼちぼち好評だったので、同様のものを土曜日に行う旨を告知した。 その結果、個人的に親交がある某web系の会社から4人と、弊社から僕含めて2人の計6人が集まった。 僕は2年目、他の人達は1年目で、歳も近い。 しかも、同じようなメンバーで4月にAnsibleの会をひっそりと行っていたこともあり、いわゆる顔見知りの集まりだった。 当日の流れ 0900 会場(弊社)集合 0900 - 1000 TDDについて、t-wadaさんの資料を見たりして全員の認識を合わせ
Martin Fowler's Bliki in Japanese - ユニットテスト
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった （この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ）。 ユニットテスティングは
power-assertができるまで
power-assert を作るきっかけ アサーション失敗時の情報量を大幅に増やすことができるPower Assertの系譜 - Togetterまとめ chai/should/expect.js 覚えること多くて煩わしい 自分で作ろうと思い立った(2013/01/08) AST 変換 power-assert は最初から AST 変換で実現しようと考えていた Groovy の Power Assert が AST 変換を行っているらしいことは何となく知っていた Groovy 1.7 Power Assert パワーアサート(Power Assert)の真の意味 Groovy 1.7のキモはAST変換である 実装を見てはいないので、 Groovy の Power Assert が最近 AST 変換を行っていないらしいことは知らなかった…!
どうやらテスト駆動型開発は死んだようです。これからのCI
SideCI主催のVenturesCI.rb #1のLT資料です。 「どうやらテスト駆動型開発は死んだようです。これからのCI」です。 要約すると、TDD死んじゃった。テスト自体は否定しないし有用だと思う。でも、ユーザに触れるEndToEndの振る舞いのテストを主に書き、テストカバレッジ100%を目指す時代は終わった(コストが高過ぎる。自転車の補助輪のようなものだ、テスト駆動型はもう外そう！)。EndToEndテストはCapybaraがよさそうだね。という内容です。
Web APIを利用するiOSアプリのテスト技法 - cockscomblog?
もう先週ですが、表題のタイトルで「Consumer Service Engineer MeetUp Vol.1 ~iOS編~」という会でお話しさせていただきました。 このようなタイトルの発表にした理由についてですが、はてなとしてお話しするということで、ちょっと硬派な方に振ってみました。結果としては良いバランスだったのではないでしょうか。 発表資料を掲載します。 また以下に発表の概略を書いておきました。ご参考ください。 前提 このMeet Upの主旨が「コンシューマ向けのWEBサービス（アプリ）の企画・開発・運営をしている会社によるエンジニア向けの講演、パネルディスカッション、懇親会を含めたMeetUpです！」となっていましたので、それではWebサービスとアプリを繋ぐWeb APIについて、それを利用するiOSアプリについて考えます。Web APIというのは古くて新しい話題で、いまや専らJS
Objective-Cで非同期処理のテストをシンプルに書く方法 | TOKOROM BLOG
非同期処理のテストってどう書いてますか？ 標準のXCTest自体がサポートしていれば良いのですがそうではないので、非同期処理のテストを書きたい場合には、その仕組みを自作するか出来合いのライブラリを利用する必要があります。現実的な選択肢としては、 GHUnitやKiwiなど非同期処理をサポートしたテストフレームワークを利用する GHunitの非同期処理のテストの仕組みを真似て抜粋したライブラリを利用する（意外とこれが多いかも？） expectaなどのマッチャーライブラリに付属の非同期処理の仕組みを使う となるかと思います。 ただ、私が調べた時点だとどれもしっくりきませんでした。 まず、GHUnitやKiwiなどを採択している場合には良いのですが、非同期処理のテストを書くという目的だけのためにそれらのフレームワークを使うというのは冗長すぎます。 また、GHUnitの非同期処理の仕組みだけを抜き
設定のクラスを作るとすっきりしそう - hitode909の日記
設定のテストを書くとよいって言ってる人がいた． 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; テストされてるのはよいと思う．名前のついてないデータ構造をがんばってテストするよりは，設定のクラスを作るとすっきりしそうと思った． こういう構造のHash，として見るよりかは，設定クラスのインスタンスとして見るほうがイメージしやすい． 個々のブログの設定のURLはユニークであるというのを，どこかのクラスの責任にする．BlogConfigRepositoryというクラスのインスタンスが，設定の集合を持ってるとか． like exception { BlogConfigRepository->new([ { "url" : "http://blog.example.com/", "permission" : "public", "members"
設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
テスト駆動開発／振る舞い駆動開発を始めるための基礎知識
連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」（Test Driven Development、以下「TDD」）は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。 本稿では、そうしたTDDの発展や、振る舞い駆動開発（Behavior Driven Development、以下「BDD」）など他のテストファースト手法への展開についても解説します。 ※編集部注：ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J
テストについての個人の雑感 - tokuhirom's blog
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tddbc/javascript-mocha: skeleton for Node.js users.
