自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
Vue.js ユニットテストの基本まとめ - Qiita
Vue.js アプリでユニットテストを書くには、Vue Test Utils や Jest など、知っておくべきことがそれなりにあります。 現在、Vue CLI でアプリを作っていますが、ユニットテストを書くために色々と調べないといけませんでした。 今回はその過程で理解した Vue.js でのユニットテストの基本を以下にまとめます。 Vue.js のユニットテスト まず、Vue.js では何を「ユニットテスト」として考えるのかを整理します。 ユニットテストの単位 Vue.js アプリは、複数のコンポーネントで構成され、それぞれのコンポーネントが連動しながら動きます。 そのため、ユニットテストの単位は「コンポーネント」となり、コンポーネントごとにテストを書いていきます。 何をテストすべきか？ コンポーネントごとにユニットテストを書くということですが、コンポーネントのどの部分に対してテストを書
テストコードを書き始める前に考えるべきテストの話 #DevSumi / Developers_Summit_2020
以下のイベントの投影資料です。 https://event.shoeisha.jp/devsumi/20200213/session/2364/ 発表時の諸注意など http://nihonbuson.hatenadiary.jp/entry/2020/01/31/090000 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P2 Agile Testing Fellow https://agiletestingfellow.com/ P15 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf P20 概説テスト分析 http://ww
TestRail ドキュメント (v8.0.1)
テクマトリックスが作成したドキュメントです。使い始めの方向けのTestRailの操作のトレーニング動画や操作を学ぶためのチュートリアル、管理者が最初に設定すべき内容やよくある質問などをまとめています。 ドキュメントガイド 本サイトでは TestRail に関するさまざまなドキュメントを公開しています。ご利用の目的に合った最適なドキュメントをご確認いただくためのガイドを用意しています。 管理者ガイド TestRail を使い始めるためのセットアップやユーザー管理、カスタマイズに関する情報を記載しています。これから運用を開始したり、TestRail の評価を行う TestRail 管理者の方はご一読ください。 チュートリアル TestRail でテストを管理するための基本的な操作を習得するためのチュートリアルです。TestRail におけるテスト管理の流れをサンプルデータを使って学習することが
Autify(オーティファイ), AIを用いたソフトウェアテスト自動化プラットフォーム - Autify(オーティファイ)
ユーザーが使うように操作をすれば一連の内容がそのままテストシナリオに。非エンジニアや入社まもないメンバーもすぐにテストを作り始めることができるのでテスト自動化をスケールさせられます 詳細ページへ
時間がない時のテスト項目書の作り方 - Qiita
開発期間が短いプロジェクトでも、しっかり試験を行うには プログラムの品質を高めるには、試験工程でどれだけ良いテストを行ったかも鍵になります。 試験工程で良いテストを行うには、良いテスト項目書が必要です。 開発期間の短いプロジェクトでは、試験工程になかなか時間を割けないものですが それでも、短い時間で良いテスト項目書を作成する方法を……まずは自分のやってきたことを以下に纏めてみます。 時間がない時にまずやること 以下の作業を通し、テスト対象となるシステムを理解します。 要件定義を機能ごとに理解する 業務フローを、要件定義を意識しながら理解する 設計書を、要件定義・業務フローを意識しながら理解する 画面項目を、要件定義・業務フロー・設計書を意識しながら理解する DB項目を、要件定義・業務フロー・設計書・画面定義を意識しながら理解する 2.の業務フローの理解の時点で要件定義と合わない箇所を見つけ
結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか？という記事で（私の記事をきっかけとして）テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ
Spring Bootとユニットテスト環境の設計について - Qiita
概要 Spring Bootを利用したWebアプリケーションにおいて、実装・保守しやすいユニットテスト環境の設計について考えたことをまとめた、ある意味考察的な内容の記事です。 設計よりの記事なのでテストコードの具体的な書き方には触れていません。 環境 Windows 10 Professional Java 1.8.0_162 Spring Boot 2.0.0 JUnit 4.12 Maven 3.5.2 参考 Spring Boot Reference Guide - Part IV. Spring Boot features - 43. Testing Spring Framework Documentation - Testing Spring Data JPA - Reference Documentation デモアプリケーション プロジェクトの構成 パッケージの切り方 このデ
AndroidStudio + PowerMock でstaticメソッドをmockする - Qiita
転載元: Yukiの枝折 - Android : AndroidStudio + PowerMock でstaticメソッドをmockする 確認環境 Android Studio 1.1 Android Gradle Plugin 1.1 JUnit 4.12 PowerMock 1.6.2 はじめに Android Studio 1.1(android gradle plugin 1.1)からUnitTestがサポートされた. 今回はPowerMockを使ってstatic methodをモックするUnitTestを書いた. Android StudioでUnitTestを開始するには下記を参考. Unit testing support - Android Tools Project Site Gradle Plugin 1.1.0-rc1でJVMでテストを実行出来るようになったらしい
ServletテストとMockito - MoChiwakiブログ
Servletのテスト方法 例えばこんなServletがあります。 DaoからDBのListを持ってくるServletクラス protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html;charset=UTF-8"); request.setCharacterEncoding("UTF-8"); //DaoクラスからなんかのList取ってくる Dao dao = new Dao(); List<Dto> list = dao.Check(); request.setAttribute("list", list); request.getReque
Javaの道：JUnit（２．基本操作）
例題 例題で使用するプログラムはコマンドライン引数で指定された文字列を数値に変換するものです。このプログラムが正しく動作するかを確認するテストプログラムを作成していきます。 動作確認するプログラム public class ChangeNum { public static void main(String[] args) { ChangeNum cn1 = new ChangeNum(); //(1)オブジェクト生成 cn1.changeNum(args[0]); //(2)changeNumメソッド呼び出し } int changeNum(String s1) { int n1 = Integer.parseInt(s1); //(3)数値に変換 return n1; } } (1)ChangeNumオブジェクトcn1を生成します。 (2)コマンドライン引数で指定された値を引数に取り、
Mockito 初めの一歩 - Qiita
テストコードでは必須と言ってもいいくらいにお世話になっているモックライブラリ「Mockito」 最低限の使い方というか、実際よく使っているパターンを紹介します。 モックって？ モックライブラリを使ったことがない方は、モックするという事自体に馴染みがないと思います。 例えば、テスト対象のクラスAが別のクラスBに依存している場合に、クラスAのテストコードなのにクラスBを初期化する処理を長々と書いたりするのは余計な手間です。もしクラスBがビジネスロジックなら目も当てられないテストコードが出来上がります。 モックライブラリでは、クラスBをクラスB自身の実装に依存しないmock(ハリボテ)として生成し、更にそのメソッドの戻り値を任意に設定するという事ができます。これにより「クラスBがこういう状態でこういう値を戻す場合のクラスAのテスト」が容易に書けます。 そしてそのモックライブラリの注目株が Moc
失敗から学ぶテスト自動化導入で大切なこと
Cybozu Meetup : テスト自動化 https://cybozu.connpass.com/event/83960/ テストをとりあえず自動化してみたけど、継続的に運用ができなかった。 そんな失敗を分析し、テスト自動化をどのように推進しているかを紹介いたします。
Webブラウザの操作をJavaScriptで自動化。Headless Chromeのフレームワーク「Puppeteer」がバージョン1.0に到達。ChromeのDevToolsチームが開発
UIを持たずスクリプトから操作可能なWebブラウザのHeadless Chromeを利用するためのフレームワーク「Puppeteer」がバージョン1.0に到達した。Webアプリケーションの自動テストなどに利用可能だ。 GoogleのWebブラウザ「Chrome」は、ユーザーインターフェイスを持たずコマンドラインやリモートデバッグ機能を通じてWebブラウザを操作できる「Headless Chrome」機能を備えています。この機能は2017年6月にリリースされた「Chrome 59」から実現されたものです。 Headless Chromeを利用すると人間がWebブラウザをマウスやキーボードで操作することなく、プログラムでHeadless Chromeを起動し、特定のWebページを読み込み、画面キャプチャの取得や、指定された場所をクリックし、値を入力し結果を取得する、といった操作を自動的に行わせ
Overview of Puppeteer | Chrome for Developers
Puppeteer is a Node library which provides a high-level API to control headless Chrome or Chromium over the DevTools Protocol. It can also be configured to use full (non-headless) Chrome or Chromium. The Chrome DevTools team maintains the library, but we'd love your help and expertise on the project. See Contributing. What can I do? Most actions you can take manually in the browser can be done wit
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織にテストを書く文化を根付かせる戦略と戦術（2019夏版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition
RSpec でコマンドの出力をテストする - わからん
Rspecでbinding.pryを行いたい - Qiita
