たまたま社内で自分が主催しているアジャイルに関する勉強会で BDD (Behaviour-Driven Development) の話をすることがあった。 個人的には、「Given, When, Then でテスト書くやつでしょ？」といった形で Gherkin記法 だけが一人歩きしている印象があるためその誤解を解くことを目的にその勉強会では話題に挙げたのでその熱が冷めないうちに自分の認識のメモを残しておきたい。 とはいえ、 https://cucumber.io/docs/bdd/ を読めば全てが書いてあるので気になった人はそちらを参照して欲しい。 前置きはそれくらいにしつつ、上記のドキュメントの中から抜粋してきた以下の画像が BDD の全体を示している。 この図が言わんとすることは、 BDD というのは Discover Formulation Automation の3つのステップで構
Test which reminded me why I don't really like RSpec | Arkency Blog (日本語訳：Rails: RSpecが好きでないことを思い出したテスト（翻訳）｜TechRacho by BPS株式会社) を見ての感想。 元のコードのイマイチなところは 4 つあって、 params を before で書き換えている *1 it "will succeed" の文言 it { is_expected.to be_success } と expect(result.success?).to eq(true) が混ざっている let が不思議な順序で連発されていて事前条件を読み解けない すべて、これによって何をテストしているのかが分かりづらくなっているという問題を引き起こす。 params を before で書き換えている let(:pa
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
昨日のRails Developers Meetupで綺麗なテストコードの書き方について発表してきました。 Rails Developers Meetup #1（東京会場） - connpass 資料はこちら 余談 もともと数年前くらいから、テストコードの書き方についてまとめたいなーと思っていたのですがなかなかキッカケがなくて手を付けられていませんでした。今回のミートアップ駆動で一通り形にするところまでいけて今とてもスッキリした気持ちです 😇 もっと多くの人にテストコードの書き方を意識してもらいたいので、また機会があればどこかで喋りたいですね。 昨日発表した内容はGitHubリポジトリにまとめたものの一部です。綺麗なテストコードの書き方について詳しく知りたい方は下記のリンクからどうぞ。 willnet/rspec-style-guide お願い 今回まとめた内容はあくまで僕が考えるテスト
とか書いてあるじゃないですか。# => を挟んで、左辺が式で右辺がその結果というやつ。 それ、でも、どんだけ信じていいの? そのコメント作るだけであれば JoshCheek/seeing_is_believing で作れるんだけど、逆がないんだよね。 というわけで作った。 https://rubygems.org/gems/xmp2assert 実装について ごくラフなアイディアとしては actual # => expected って書いてあったら assert_equal(expected, actual) に変換する。これが着想。 とはいえこの式はRubyの式なわけで、正規表現置換のような生易しいことにはならない。Ripperでがんばってコメント位置を発見して、その直前にある式を…… みたいなのをやっていて非常に面倒。 このコメントはコメントであるがゆえに実行時には読み飛ばされるので、
この記事は、はてなエンジニアアドベントカレンダー2016の5日目の記事です。 こんにちは、はてなでアプリケーションエンジニアをしている id:shiba_yu36 です。先日、buildersconにおいて、現在所属しているプロジェクトでJavaScriptのユニットテストを導入した知見について、「一から始めるJavaScriptユニットテスト」というタイトルで発表しました。 speakerdeck.com この発表は、実際にJavaScriptのユニットテスト環境を作ってみると非常にハードルが高いと感じたので、そのハードルを少しでも下げられればという思いで、非常にシンプルな例で一から環境を作る例を紹介しました。アジェンダは次のとおりでした。 カクヨムのJS環境 JSのテストツールを整理する 通常の関数のユニットテスト DOM操作する機能のユニットテスト カクヨムのJS環境や、JSのテスト
2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
Overview Oktest is a new-style testing library for Python. from oktest import test, ok, NG class FooTest(unittest.TestCase): @test("1 + 1 should be 2") def _(self): ok (1+1) == 2 # same as assertEqual(2, 1+1) @test("other examples") def _(self): ok (s) == 'foo' # same as assertEqual(s, 'foo') ok (s) != 'foo' # same as assertNotEqual(s, 'foo') ok (n) > 0 # same as assertTrue(n > 0) ok (fn).raises(E
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
