フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ
「5人でユーザテストすればユーザビリティ上の問題のうち85%が見つかる」の元ネタ論文を解説する｜Mikio Kiura / ANKR DESIGN
Webサービスやアプリなど開発や運用に関わっている方であれば、こんなことを耳にしたことがあるのでは無いでしょうか？ 5人でテストを行えば、ユーザビリティ上の問題のうち85%を発見できるこれらは業界的にはある意味で常識ですが、色々話を聞いてみると、この常識の「出処」あるいは「根拠」ってあんまり知られていないようなのです。 もちろん、ちょっと知識のある人であれば、ユーザビリティ業界の第一人者であるヤコブ・ニールセン博士が提唱したというところまでは知識として知っているでしょう。しかしながら、その元ネタとなった論文を実際に読んだ人、あるいは85%という数字の根拠やその条件について理解されている方はどの程度居るのでしょうか。 ということで本記事では「ユーザテストは5人で85%」の元ネタである下記の論文について、解説、と言うとちょっと大げさかもですが、概要を紹介してみたいと思います。願わくば、この記事
DBアクセスで遅くなったテストの実行時間を Docker で 40% 削減した方法 - Qiita
DBのレイヤーを含むエンドツーエンドテストやDBに依存したコンポーネントの自動テストがたくさんあると、全てのテストが終わるまでに長い時間がかかるようになってしまうことがあります。DBのクエリ実行はネットワークIOやディスクIOなどを含んだ高コストな処理だからです。 Docker を少し工夫して使うと、お手軽にテスト中のDBのクエリ実行にかかる時間を削減できます。自動テストが完了するまでの待ち時間を短縮し、開発のフィードバックサイクルをより早く回せるようになります！ MariaDB を用いたプロジェクトの実績では、DBアクセスを伴うテストケースが 153件 ありましたが、この方法によりそのテストスイートのローカル環境での実行時間を約 43% 削減できました（約 145.7s → 約 83.3s）。 どうやって？ Docker で tmpfs を使います。 tmpfs tmpfs とは、ディス
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
Appiumの仕組みと使い方 - Qiita
はじめに 今まで Calabash や Appium を試した記事を書いてきました。 WKWebViewを使うアプリのUI自動テストにCalabash-iOSを使ってみた Appium+CucumberでiOSの自動UIテストを日本語で書く Appium を扱っていてトラブった時に、Appium の仕組みが分かっていると、原因を切り分けたりソースコードを追ったりしやすいのでまとめてみました。 詳しく解説するのは自分が利用する構成に関してのみです。ターゲットは iOS 9 で、利用言語は Ruby です。 Appium のバージョンは 1.6.0 です。 Seleniumの構成 まずは Appium の元になっている Selenium の構成から見ていきましょう。Selenium はブラウザ上で動作する Web アプリケーションをテストするためのツールです。 Selenium WebDriv
一から始めるJavaScriptユニットテスト - Hatena Developer Blog
この記事は、はてなエンジニアアドベントカレンダー2016の5日目の記事です。 こんにちは、はてなでアプリケーションエンジニアをしている id:shiba_yu36 です。先日、buildersconにおいて、現在所属しているプロジェクトでJavaScriptのユニットテストを導入した知見について、「一から始めるJavaScriptユニットテスト」というタイトルで発表しました。 speakerdeck.com この発表は、実際にJavaScriptのユニットテスト環境を作ってみると非常にハードルが高いと感じたので、そのハードルを少しでも下げられればという思いで、非常にシンプルな例で一から環境を作る例を紹介しました。アジェンダは次のとおりでした。 カクヨムのJS環境 JSのテストツールを整理する 通常の関数のユニットテスト DOM操作する機能のユニットテスト カクヨムのJS環境や、JSのテスト
俺のRSpecがこんなに雑なわけがない - Qiita
ここ最近、 RSpec の書き方が自分の中で変化したので、そのことを書きます。（こういう話ちょっと今更なきもしますが...） 私の書き方は少数派だろうと思います。他の人に強く勧めるつもりもありません。 ただ、どうにも Better Spec のような書き方には疲れました。 テストを書くということはもっと気楽なものでいいように思います。 こういう書き方もあるんだよ、という程度で読んでもらえれば幸いです。 概要 ほんの一年くらい前まで Better Spec みたいな RSpec の書き方を私も心がけていました。 describe と context を使い分け、subject と it をうまいこと組み合わせてテストを作っていました。 簡単な例ですが、次みたいな感じです。 # 以下、このテストを「ケースA」と呼びます。 describe 'Book' do describe '#valid?
『C1/C1/C2 カバレッジについて』
～Rhythmical Life～ ・Music Life / ・Soccer Life / ・Trip Life アコースティックギター一本、 サッカーボール一つ、 そして身一つで、 世界を楽しむのには十分だ。 C1/C1/C2 カバレッジについて ■いつも忘れてしまうカバレッジの違いについて C0/C1/C2 検査網羅率(テストカバレージ) ── どれだけテストしたか、の指標。 例: void function(...) { if ( 条件A || 条件B ) { 処理1 } else { 処理2 } if ( 条件C ) { 処理3 } else { 処理4 } } C0: 命令網羅 ステートメント・カバレージ 通っていない処理がなくなればC0は100%となる。 この例では 処理1,2,3,4 を少なくとも1度通るべきであるということ。 つまり 処理1, 処理3 を通るケース 処理2
Railsアプリケーションを、Heroku上で1分間125,000リクエストに対応できるようにスケーリングする | POSTD
Railsアプリケーションを、Heroku上で1分間125,000リクエストに対応できるようにスケーリングする 要約： Herokuでは、Railsのスケーリングが非常に簡単できますが、考慮すべき重要なポイントがあります。DynoとPostgresのさまざまな設定がHerokuでのパフォーマンスにどのように影響を与えるかについて調べました。 スケーリングのテストをする理由 ZeeMee のサーバは、今秋、来たる大学入学のシーズンにリクエストが殺到する見込みです。学生はZeeMeeを使って入学願書に動画や写真を付加することができるので、当社のWebサービスが受ける負荷は非常に深刻なものになっています。ピーク時（大学入学の出願期限）には、リクエストのロードが平均の150倍にもなります。 今年の秋を迎えるにあたり、APIのリクエストの爆発的増加にしっかり備えておこうと考え、Herokuでパフォー
テストを育てるためにテスト管理ツール「TestRail」を使ってみた
テストケースの管理は、テスト自動化云々の前になんとかしておきたいところ。テストケースはExcel管理することが経験上多いですが、世の中にはもっと便利なものがあるだろうと思い、ブラウザベースでテスト管理できる「TestRail」を試してみました。さてさて、Excelを超えるのでしょうか？ 超えてみろ！ なぜテスト管理が重要なのか テストケースの管理について、以下のような課題を多く経験しました。 テストケースの追加や更新、その後の整理が難しい。行のコピペミスやマージ漏れ、同時更新でおかしくなったりファイルが壊れたり。マスタとなるテストケースをバージョン管理しながら育てていきたい。 トラッキング情報を書き込みにくい。Excelのセルには表示限界がある。「5/31 藤原 XXXXX追加」とか書くのがとても面倒くさい。 過去のケースを検索しにくい。ファイル・フォルダに行って、過去の日付のケースを開い
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
無料パフォーマンステスト | 負荷テスト
これまで、負荷テストの実行には専門知識と実行環境の準備に多くのコストが必要でした。社会からWebサービスの性能に関する不具合をゼロにするために、簡単、無料、圧倒的な負荷テストサービスを提供します。 ユーザビリティ サーバの応答速度は常に変化し、利用者の直帰率に大きく影響を与えます。サーバの応答速度を可視化し、日々計測することで、すみやかに問題個所を発見できます。 性能測定 サーバの性能不足により、せっかくの営業機会を失うサイトが多く存在します。サーバの性能を正しく把握することで、予測される負荷に応じたサーバの増強ができます。 負荷チェッカー／カレンダーを利用したテスト（ジョブ）の予約や、グラフィカルな結果画面を準備しており、初心者の方にも大変使いやすいサービス。インスタントテスト／URLを入力するだけで、すぐに負荷テストを行うことができます。シナリオテスト／ログインが必要なページや複数のペ
アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組
はじめに これはソフトウェアテストあどべんとかれんだー 2014 の17日目の記事です。 id:a-suenamiがテストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)で僕が考えているモデルについて紹介してくれていたので、ざっくりとですが僕の方から「現状の僕が捉えているソフトウェア開発。そしてテスト。」について紹介します。これはここ数年における僕の最高傑作とも言えるコンテンツに関するエントリです。（言いすぎだ 概要 言い過ぎればプロダクト開発というものは「Define, Build, Explore, Measure」という活動から成立していると言えます。これに知識や手法やプロセスをあてはめると「何をやるべきか」「何が足りていないか」がわかりやすくなります。この記事ではそういった開発やテストを
テストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)
このエントリは ソフトウェアテストあどべんとかれんだー 2014 の 6 日目のエントリです。 前日は Yuji Yamamoto さんの『より「普通に」書くためのTest Doubleライブラリ「crispy」 #ruby #SWTestAdvent』でした。 Ruby Advent Calendar と同時寄稿というのはおもしろい試みですねー！僕も Rubyist の端くれなので大変参考になりました。 さて、僕は具体的なテスト実装の話ではなくもうちょっとプロセス論寄りの話をします。もっと率直に言うとポエムに近いです。 自己紹介 すえなみと申します。漢字で書くと末並です。「末波」とよく間違われますが「末並」です。 とても希少な名字なので勉強会等で「すえなみ」と名乗ってる人間がいたら間違いなく僕のことだと思ってください。 オンラインでは a_suenami とか a.suenami とかで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dredd — HTTP API Testing Framework — Dredd latest documentation
Getting Started with Create React App and AVA - Semaphore
移動しました - SmartHR Tech Blog
あなたの安心を高速に守る Container-based CI
Rubyでブラウザを操作できるGem watir - 酒と泪とRubyとRailsと