t-wadaさんから直接学ぶ！TDDワークショップ開催レポート - pixiv inside
みなさんこんにちは！ピクシブで唯一(?)のテストエンジニアの @shimashima です。 6月28日にTDDの伝道師として有名な t-wada こと和田卓人さんを講師として招き、1日かけてのテスト駆動開発(以下TDD)ワークショップを開催しました。 本日はピクシブ株式会社様にて、1日コースのテスト駆動開発ワークショップの講師を務めさせていただきました。ご参加くださいました皆様、誠にありがとうございました！— Takuto Wada (@t_wada) 2018年6月28日 今日はその様子を紹介したいと思います。 開催のきっかけ 開催のきっかけは、自分が実行委員を務めているJaSST '18 Tokyoにて和田さんによるTDDチュートリアルを聞いたことです。 このチュートリアルの登壇依頼を行なったのも私なのですが、恥ずかしながらそれまでTDDは話に聞いただけで、各地で開催されているTDD
TDDはあんまり使わなくなったけど心の中にある - Mitsuyuki.Shiiba
今日は娘たちとコログ探しして楽しかった。 この数年間、頭の中にTDDを入れた状態で開発をしてきたんだけど。タイトルに書いた風に思う。 良い所がいっぱいある 見失わずに済む 僕にとってTDDの良さは、まず、自分が何をしようとしているかを見失わずに済むところ。一歩先にゴールを立てて、そこに向かって一歩進む、たどり着いたら、次の一歩を進める。その繰り返し。だから、遠く離れたゴールに対して、急いで走って、途中で道に迷ってどこに向かってるか分かんなくなったりしないで済む。 余計なものを作らなくて済む 「必要なものはこれだよね？」という確認から入って、それを実現するための実装に集中するから余計なものを作らなくて済む。実装を先に作ると「こういう機能もあるといいかもだから入れとこうかな」ってついつい入れてしまう。 リファクタリングできる まず最初に動くものを作ってから、その状態をキープしたまま、実装の改善
TypeScript+mocha+power-assert+empowerでカバレッジをとってついでにCircleCI+Codecov - Write and Run
表題のとおりだが、更に CircleCI のビルドを高速化するために yarn を使うぞ。 やりたいこと 最新の TypeScript を使う 1.8 とか使わない テストコードも TypeScript で書く empower する 明示的に require('power-assert') しない source map が生きてる状態でカバレッジを取る TypeScript の行ベースで結果が出る やりたくないこと 中間ファイルの生成 やっていく ガンガン入れる。 yarn add --dev typescript ts-node babel-register babel-preset-power-assert power-assert mocha nyc @types/mocha @types/node この状態で、 mocha --compilers ts:ts-node/regist
Karma, Mocha, Chaiを使ってTypeScriptでのテスト環境を構築する - $shibayu36->blog;
最近はTypeScriptを使ってフロントエンドの開発をしている。 JSをbrowserifyでビルドし、ライセンスコメントを適切に残す - $shibayu36->blog; gulp + browserify + tsifyを利用してTypeScriptコンパイル環境を作る - $shibayu36->blog; typingsを使ってnpmモジュールをTypeScriptで利用する - $shibayu36->blog; 以上の記事に引き続き、次はTypeScriptでユニットテストをするためのシンプルな環境を構築してみた。 今回のサンプルコードは https://github.com/shibayu36/typescript-project-sample/tree/967c9d74fd3d844127a4352f19a0cc31b7a0690d においてあるので、見ながら確認しても
Mockitoの真価はspyにあり - R42日記
以前の日記でEasyMockをご紹介したのですが、現在の現場ではMockitoを使っています。 それにしてもモックキット？モキット？モキート？どう読むんだろう… ロゴは有名なカクテル「モヒート」ではあるが。僕はミントが苦手なので余り飲まないけど。 Mockitoは比較的新しいモックユーティリティです。 何か革新的な機能を備えているかというとそうでもないのですが、使い勝手が非常に良いのが特徴。 サンプルコードはこんな感じ。 public class VeryHugeBusinessLogic { void doSomethingHardProcessing() { ... } } public class VeryHugeService { @Autowired VeryHugeBusinessLogic logic; public void execute() { logic.doSome
テストがない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
TypeScript でユニットテストする。カバレッジもねっ!! - Syati.info
AltJs ってトランスパイルした後、テストを実行させる必要があるから・・、面倒くさいんだよね。なんか、あまり情報もないし、これだから AltJs は・・・と思うわけですが、やってみると案外大したことないもんです。 今回は、TypeScript のコードのユニットテスト、カバレッジを記していこうと思います。本記事のコードは以下のURLにあります。 https://github.com/Syati/typescript-sample/tree/master/011_test_sample Step 0: 事前準備 流れ ts でコードを書く トランスパイルする（js と map を出力） js をテストする map を利用してts カバレッジを測る ライブラリ npm install -g mocha istanbul remap-istanbul でそれぞれコマンドが利用できるようになりま
【速報】JUnit5 はこうなる!?【プロトタイプ】 | DevelopersIO
渡辺です。 DevelopersIOでの100本目のエントリーがJUnitネタとなりました。 自分がJUnit実践入門を執筆したのは2011年から2012年にかけてです（出版が2012年11月）。 それからJava8がリリースされていますが、JUnit4自体は大きな進化はしていませんでした。 昨日、JUnit Lambda Prototypeが公開されました。 まだプロトタイプということで、今後の変更は大きいかと思いますが、いよいよ次世代のJUnitの足音が聞こえてきた感じがします。 今回は、このドキュメントからJUnit Lambdaの概要と方針について速報をお送りしたいと思います。 なお、現在JUnitチームでは、このプロトタイプに対するフィードバックを募集しています。 ここはこうじゃないとかはてブコメントする前にTwitterやGitHubでフィードバックを！ JUnit Lambd
jasmine-maven-plugin – Jasmine Maven Plugin
As one might intuit, the jasmine-maven-plugin is a Maven plugin for the JavaScript testing framework, Jasmine. If you’re using Maven, you’re probably writing Java (but, hey, you could be using it for any JVM-language). And if you’re anything like me, you’re here to figure out how to treat your client-side code with the same degree of professionalism that you already show server-side code. Maybe th
AssertJ / Fluent assertions for java
AssertJ Core site has moved to https://assertj.github.io/doc/ This site is still maintained for AssertJ modules (until their documentation is migrated) Rich and easy to use AssertJ provides a rich set of assertions, truly helpful error messages, improves test code readability and is designed to be super easy to use within your favorite IDE. Get started right away with the one minute starting guide
JavaのテストにはAssertJがオススメ - Qiita
JavaでのテストはJUnit4が使われていると思いますが、自分としては、それに加えてAssertJをオススメします。 AssertJ AssertJが使いやすい理由 JUnit4のassertThatと比べてAssertJが使いやすい理由は2つあります。 流れるようなインターフェース AssertJは「Fluent assertions for java」とトップページに大きく書かれているように、流れるようなインターフェースが最大の特徴です。いちいちドキュメントを調べなくても、IDEの補完機能で適切なメソッドを調べられるので、JUnit4のassertThatに比べて書きやすいです。 拡張がMatcherに比べて遥かに楽 Matcherの拡張対象は「比較方法」で、AssertJの拡張対象は「クラス」なので比較するのは適切ではないかもしれませんが、Matcherの拡張が靴の上から足を掻く感
イマドキのJSテスト - テスト環境をモダンフロントエンドツール群で整備する編 〜 JSおくのほそ道 #032 - Qiita
こんにちは、ほそ道です。 今回はビルドツール・モジュールローダ・altJS(JSコンパイラ)を組み合わせてさらにテストコードのおくのほそ道に入り込んでいきます。 今回Gulp + Webpack + Karma + Jasmine + ES6を使用しますが、 GruntだったりBrowserifyだったりMochaだったりCoffeescriptだったりに置き換えても基本的な考え方は近しい感じになるかと思います。 あとはここにSPAフレームワークとかを組み合わせればいよいよモダンなテストコードになっていきますね。 目次はこちら 今回解決すること・設計方針 Webpackとテストコードを組み合わせる。なんかバンドルしたりごにょごにょやってるどこにテストを挟むのか？を解決する。 ソースコードもテストコードもES6で書く。babelないしはaltJSのコンパイルごにょごにょやってるどこにテストを
jsでTDD！MochaとChaiとsinon.js入門 - lxyuma BLOG
※この記事は社内勉強会向けの資料の下書きです。書きなぐりの下書きで見直すと最後の方の文書がヤバいので、いつか書き直します。読み辛い所は申し訳ないです。 概要 TDD テスト自動化とTDDを整理 TDDとBDDの違い Test Framework in javascript QUnit/jasmine/mochaについて、違いやメリデメを知る mocha 基本的な書き方 アサーションライブラリのメリデメを整理する chai 記述形式の違い整理 基本文法 sinonjs spy stubs mock TDD Test Driven Development テスト駆動開発 by ケントベック 特徴 xUnit系/BDD系のテストフレームワーク使う テストするコードも実装 テストファースト 実装の後にテストするのではなく、テストを先に書いて実装する サイクル Red(失敗) => Green(通過
Arquillian で JAX-RS のテストを書くときはこんな感じでどうだろう - なにか作る
Arqullian を使っている。 ちょっとずつ書き方がわかってきた気がする。 サンプルコード @RunWith(Arquillian.class) @UsingDataSet("dataset.yml") public class CountryResourceTest { @ArquillianResource private URL baseUrl; private URI countryUri; @Before public void init() throws Exception { countryUri = UriBuilder.fromUri(baseUrl.toURI()) .path(ApplicationConfig.class.getAnnotation(ApplicationPath.class).value()) .path(CountryResource.cla
Martin Fowler's Bliki in Japanese - ユニットテスト
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった （この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ）。 ユニットテスティングは
テストできないコードをE2Eテストを使ってリファクタリングしよう
ユニットテストがしにくい状態となってるコードをTestiumを使ったE2Eテストを書いてリファクタリングしてみる話です。 例えば、以下のようなjQueryで書いたコードは外(テストコード)から取り出すポイントがないので、ユニットテストを書くのは難しいと思います。(そもそもViewのコードなので) 特定のバージョンでの変更点を簡単に確認できるよう、 「Aの列のラジオボタンを選ぶと同じ行より一つ下にあるBの列のラジオボタンを自動で選ぶ」 という補助機能 $(document).ready(function () { // seq: シーケンス番号 $.each(["new_version", "old_version"], function () { $("input[name='" + this + "']").each(function (idx, elem) { if (idx == 0
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Vueコンポーネントのユニットテスト
TypeScriptでpower-assertを使う時の注意点 - Qiita
Testing an Angular Application: Angular JS and Spring Security Part VIII