You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています(経歴)。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
はじめに 弊社ソニックガーデンの中でも「この本、面白そう」と少し話題になった「ソフトウェアテスト技法練習帳」を買って読んでみました。 ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~ 作者:梅津 正洋,竹内 亜未,伊藤 由貴,浦山 さつき,佐々木 千絵美,高橋 理,武田 春恵,根本 紀之,藤沢 耕助,真鍋 俊之,山岡 悠,吉田 直史出版社/メーカー: 技術評論社発売日: 2020/01/07メディア: 単行本(ソフトカバー) このエントリでは本書を読んだ感想をざっくりまとめておきます。 本書の概要と目次 最初に、本書の概要と目次を技術評論社の書籍ページから引用します。 この本の概要 新人や経験の浅いテストエンジニアにとって,座学で学んだ「ソフトウェアテスト技法」を実務に活かそうにも,どのように適用したらよいかわからないというのが悩みです。そこで,本書では実践的なシチュエーションを
※注意:この記事には主観とグチが含まれています。 コードのカバレッジ取得サービスを調べてみました。Coveralls.ioとCodecov.ioの比較です。 ↓こんな感じのバッジがREADMEに表示されるやつです。 TravisCIなどで自動テストを行い、ついでにテストのカバレッジも取得している方は多いと思います。 カバレッジを取得できるCIサービスだと coveralls を使っているプロジェクトが多いようですが、自分が試した時はなんか反応が鈍かったりgithubのリポジトリの更新が上手く反映されなかったり(中略)ったりとあまりいい印象がなかったので、他のサービスも試して比べてみました。他というかCodecovしか試してませんが。CodecovはSideCIさんのブログ記事で知りました。ありがとうございます。 結論:Codecovいい感じ!おすすめですよ! 利用方法 どちらも公開リポジト
Linuxカーネルにローカル権限昇格脆弱性「Dirty Frag」 ─ PoC公開、各ディストリビューションが対応進める 5月9日 22:51
ブラウザ拡張Selenium IDEで ユーザー操作を記録・再現できる! UIテストの自動化に活用しよう Selenium IDE(セレニウム・アイディーイー)とは、ブラウザ操作を記録・再現できるChrome、Firefoxで利用可能な拡張機能(アドオン)です。 手軽に記録・再現ができるため、アイデア次第で色々な使い方ができます。筆者は、会社の打刻操作(社内サイトへアクセス → ログイン → 打刻ページへ遷移 → 打刻ボタンをクリック)を記録し、自動実行することでいち早く出社ができるようにしていました。 その他にも開発時に繰り返し行うようなデバッグ作業やルーティーン作業を記録することで、以下のような活用もできます。 入力フォームなどに文字を入力する操作を記録しておき、自動入力させる。 ゲームやSPAのデバッグ時に、スタート画面からデバッグしたい画面までの移動操作を記録しておき、任意の画面へ
この記事はDan North氏の記事「Introducing BDD」を氏の許可を得て翻訳した公式版("the official translation")です。(原文公開日:2006年9月20日) 私は1つ問題を抱えていました。様々な環境にあるプロジェクトでテスト駆動開発(TDD)のようなアジャイルのプラクティスを用いたり、あるいは教えていると、いつも同じような混乱や誤解に行き当たったのです。プログラマが知りたいと望むのは、どこから始めれば良いのか、何をテストすれば良いのか、何をテストする必要がないのか、1つのものに対してどの程度テストすれば良いのか、テストをなんと呼べば良いのか、テストが失敗した理由をどう理解すれば良いのか、ということでした。 TDDに深く入り込むほどに、自分の道程が、言われたことをコツコツやれば徐々に上達するようなものではなく、むしろ行き詰まりの連続であると感じました
What is Better Specs Better Specs is a collection of best practices developers learned while testing apps that you can use to improve your coding skills, or simply for inspiration. Better Specs came to life at Lelylan (open source IoT cloud platform) and checking out its test suite may be of inspiration. Better Specs focus on Rails testing, but our goal is to create testing guidelines covering mos
The latest news from Google on open source releases, major projects, events, and outreach programs for early career developers. Usage of containers in software applications is on the rise, and with their increasing usage in production comes a need for robust testing and validation. Containers provide great testing environments, but actually validating the structure of the containers themselves can
One may ask: do we really need a special tool for creating mock objects in TypeScript, while there are several robust libraries written in JavaScript? We can use Mocha or Jasmine as a test framework, we can also use Karma and Chai—they’re all JavaScript libraries and work successfully, so why can’t we use Sinon.JS for mocking? It’s all about typesDeveloping a quite large application (over 500 clas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く