「テスト駆動開発から品質保証へと橋を架ける」 ソフトウェアテストシンポジウム 2018 関西(JaSST'18 Kansai) 基調講演 2018年6月15日(金) 東リ いたみホール(伊丹市立文化会館) http://jasst.jp/symposium/jasst18kansai.html
状態遷移テスト - state transition testing - WACATE 2018 夏での状態遷移テスト説明資料。 WACATE 2018 summer http://wacate.jp/2018/summer/program.html
Standalone, framework-agnostic JavaScript library that enables recording, replaying, and stubbing HTTP interactions.
2016年11月3日(祝)、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 <この記事の要約> 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ(未視感)が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発3部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。(本で確認してみてね) 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に1回だけパターンを使って
・ログイン後の一覧画面に遷移して、ID/パスワードのアサーションとキャプチャ ・リストで以下の要素を登録してキャプチャ(入力したものが、画面にリンクとして反映される) 入力値:javascript, ruby, scala ・リストの順番を入れ替えてキャプチャ 別タブの操作 別タブを開くリンクをクリックする (別タブの操作)タイトルをアサーション・キャプチャ (別タブの操作)タブを閉じる 元のタブでキャプチャする ブラウザバック・フォワードの操作 リストの任意の項目(同タブリンク)をクリックする タイトルをアサーションして、キャプチャ 一覧画面に戻る、進むを行い、それぞれでキャプチャする テストコード 上記で用意したテストケースを網羅できるテストコードを書いていきます。 const puppeteer = require('puppeteer'); const loginUrl = 'ht
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか? react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
JaSST'18 Tokyoは2日間で延べ1600人を超える方にご参加をいただき、盛況のうち終了しました。多くのご参加をいただき有難うございました。 当日の各種資料・レポートはこちらからご覧下さい 「善吾賞」のご案内 善吾賞は、この1年間に発表されたソフトウェアの品質向上に寄与する学術的な論文を顕彰するもので、今回は、2016年10月から2017年9月までに発表された日本語論文及びソフトウェアテストシンポジウム2018東京採択論文を対象に、ASTER善吾賞選考委員会が選出しました。 「深層学習による不具合混入コミットの予測と評価」 ソフトウェアエンジニアリングシンポジウム2017論文集 情報処理学会, pp.35-45, 2017年8月. 近藤 将成,森 啓太,水野 修,崔 銀惠
2018/2/27(火)に和田 卓人(@t_wada)さんに、テスト駆動開発(Test Driven Development, 以下TDD)の1日ワークショップを開催していただきました! 本ワークショップは前半と後半で2部構成になります。 前半: TDDの講義およびライブコーディング 後半: TDDの実習およびt_wadaさん含む全員参加型のコードレビュー 特に後半の全員参加型のコードレビューはワークショップの特徴的な要素であり、なかなか無い機会です。人数が多いと参加者全員のコードレビューができない可能性があったため、今回は小規模(全14人)で開催しました。 以下でワークショップの内容を振り返り・議論となったポイントを記載します。 前半: テスト駆動開発とは? 午前中は、テスト駆動開発についてt_wadaさんから説明いただきました。 講演の中では、まずはじめにKent Beck氏の著書"テ
次のようなテストコードを書きます。(これはMochaを使っていますが大体どんなテストフレームワークでも同じことが出来ます。) 次のスナップショットでは、transformというJSONを入力に受け取り、JSONを出力する関数をテストしています。 snapshot-test.js: const fs = require("fs"); const path = require("path"); const assert = require("assert"); const fixturesDir = path.join(__dirname, "snapshots"); // transform function const transform = require("../transform"); describe("Snapshot testing", () => { fs.readdirSy
Takuto Wada @t_wada power-assert 関係のコードを power-assert-js organization に移管開始 (@teppeis さんのアドバイス)。ロゴが無いと寂しいので数分で適当に作ったら酷いテイストなのでプロに依頼したい… github.com/power-assert-js 2015-05-18 16:07:47
A software developer living his passion of development since 2003. In addition to always trying to improve his skills, he’s also a proud husband and an avid gamer. Introduction Angular is one of the most popular front-end frameworks around today. Developed by Google, it provides a lot of functionality out of the box. Like its predecessor, AngularJS, it was built with testing in mind. By default, A
1年半前は 業務 とか 趣味 で TypeScript を使ってテストも書いてたんだけど、最近は iOS ばかりで忘れてしまっていた。 けどまた仕事で同じような環境を作ったので、テストを書くときにどういう Framework があって役割は何かをメモっておく。 テストフレームワーク テストを書くために必要なライブラリ。 iOS でいったら Quick や XCTest, Rails でいったら rspec とかが該当する。 Mocha - the fun, simple, flexible JavaScript test framework BDD フレームワークで、 assertion の機能は持っていない Jasmine Documentation Matcher というアサーションライブラリを内部で持っているようだ Jasmine使い方メモ - Qiita Jest · 🃏 Del
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした: 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです!しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
speakerdeck.com 日本で開催されるもっとも大きなiOSに関するカンファレンスの1つであるTop | iOSDC Japan 2017に参加し、表題の内容で発表しました。 聴いてくださった方々からは好評のようでよかったです。発表資料は本題と関係のない話がちょこちょこ挟まったり、口頭の説明がないとわからないページがあり、スライドだけでは意図がよく伝わらない恐れがあるので、こちらで内容について補足します。 伝えたかったテーマは「依存が大きく複雑で、単体でテストしづらいコードを単体で動かしてテストできるようにするには」ということです。その題材として一般的に依存が複雑でテストしづらいコンポーネントであるビューを例として取り上げました。ですのでビューやUIをテストするということに絞った話ではなく、どのレイヤーに対しても複雑にいろいろな依存関係があってユニットテストが書けないという状況を改
ほぼ表題の通りの内容で、Chrome拡張を作ってみた。 完成度としてはまだまだだけど、とりあえずざっくり触れる程度にはなったので公開した。 github.com chrome.google.com アイコン画像は、カピバラの写真を適当になぞって作った。 なんでこんなものを? Capybaraのテストコードを書くのが面倒だなって感じることが多かったのが1つの理由。 TDD的に、先にテストコードを書いていけるのが理想だな〜とは思うものの、Webアプリケーションの開発をしていると、現実には一度は画面から一通り確認して、その後にfeature specを書く流れが多いように感じる。 そしてCapybaraでfeature specを書こうと思うと、 「これはテキストじゃなくてIDで選択しないとダメか〜」 「あ〜、これはfindしてからsetしないといけないのか〜」 という感じで、スムーズに書けない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く