Hypothesisとpytestを使ってDjangoのユニットテストを書く - 何かを書き留める何か
Hypothesisとは何か、プロパティベーステストとは何か Hypothesisは、Python向けのプロパティベーステストのライブラリである。 プロパティベーステストは、生成された多数の入力データに対してプロパティ(性質)が満たされるかどうかをテストする手法である。 HaskellのQuickCheckライブラリが初出で、現在は各プログラミング言語に移植されている。 従来のユニットテストは、ある程度固定したテストデータを指定してテストを行っていた。 その際、境界値分析などで妥当なパラメータを決定していた。 しかし、境界値分析が必ず通用するとは限らないし、人間が行う以上、ミスも発生する。 プロパティベーステストはデータを固定する代わりにそのデータが満たすプロパティを指定してテストを行う。 実際のテストケースはHypothesisがプロパティを満たすパラメータを決めて生成してくれる。 人力
『レガシーコードからの脱却』を読んだ - 夜は寝る
お仕事でレガシー改善っぽいことばかりやっていたら、他部署のエンジニアから「レガシーの人」と呼ばれた。老害の化身みたいな印象を刷り込まれつつある。そんなわけで、レガシーにまつわる本を読んだ。 www.oreilly.co.jp インターネットをみているかぎり評判が良さそうで、ネクストバイブル的な扱いを受けていた。読んでいて思ったことなどを雑に書き留める。 感想たち 全体的にとても読みやすく、整理されている。訳も自然。キーワードを挙げるなら、アジャイル、TDDあたり。タイトルからは少しずれる印象かもしれないが、レガシー関係なく良いコードを書く方法にかなりページを割いている。その理由は、最終章の以下文で端的に説明されている。 良いものがどんなものか知らなければ、レガシーコードをリファクタリングしてもより良いものにしようがないのだ。(p.241) 「レガシー改善やるぞ」とそれ自体が目的になってしま
TDDから僕が学んだことと最近考えてること - assertInstanceOf('Engineer', $a_suenami)
この記事は TDD Advent Calndar の 20 日目の記事です。1 日遅れました。すいません。 記事を書くことになったきっかけ こんなツイートをしたら 一周（？）まわって、TDDって一体何だったんだっけ？っていうのを考えている。— ベーシック焼肉 (@a_suenami) 2020年12月6日 見つかってしまいました！ その考えのアウトプットをお待ちしてます！whttps://t.co/fIFVAkuitQ— broccoli (@nihonbuson) 2020年12月6日 というわけで、最近考えてることを書きます。 何が開発を駆動するのか TDD は日本語では「テスト駆動開発」と呼ばれるが、私たちの開発はテスト以外にも多くのものによって駆動されていると思う。実際、TDD 以外にも XDD と呼ばれるもの（X には何らかの文字が入る）は数多くある。 テスト以外に開発を駆動する
テスト駆動開発の第2章は"なぜxUnitなのか"？ - Qiita
「テスト駆動開発」を読んだ違和感 私は社内でテスト駆動を布教してしまう程度には、テスト駆動が好きです。そのため、ことあるごとに色んな人にテスト駆動開発の本を勧めているのですが、テスト駆動開発には独特の読みにくさがあります。 その"読みにくさ"というのは、どういうことなのか？KentBeckのテスト駆動開発は、3部から構成されています。 第1部 多国通貨 第2部 xUnit 第3部 テスト駆動開発のパターン 第1部の「多国通貨」はテスト駆動の入門の章です。ドルやフランなど複数の通貨単位を相互に変換したり、足し算や、掛け算を行うロジックを、テストファーストで構築していきます。 第2部の「xUnit」は、その名の通り、xUnit自身をテスト駆動開発で作っていきます。少し文章で表現するのが難しい内容ですが、例えば、pythonには標準でunittestというテストのフレームワークが存在します。この
『単体テストの考え方/使い方』を読んで現実的なテスト駆動エンプラ開発を考えよう - TechとPoemeの間
年末年始に『単体テストの考え方/使い方』(原著: Unit Testing Principles, Practices, and Patterns, 以下 UTPPP) を読んだ。 単体テストの考え方/使い方 作者:Vladimir Khorikovマイナビ出版Amazon UTPPP 内でも紹介されているが、テスト駆動開発 (TDD) には大きく「デトロイト学派1」と称される考え方と「ロンドン学派」と呼ばれる考え方が存在して、その最も大きな違いはモック (テスト・ダブル) に対する考え方にある。自動化されたテストによるアプリケーションのテストカバレッジを向上させる上でテスト・ダブルの活用は避けて通れないが、テスト・ダブルの利用にはメリットもデメリットもあるため、2つの学派のスタンスを踏まえた上での落とし所を見つけることが重要となる。 テスト駆動開発にはざっくりいうとモックを積極的に使う派
僕がRSpecでsubjectを使わない理由 - give IT a try
はじめに 僕は折に触れて「RSpecではなるべくsubjectを使わない方がいい」という発言をしています。 Qiitaとか見てるとRSpecのsubjectを愛用している人が多そうな印象なんだけど、僕はほとんど使っていません。「subjectは原則使わない。明らかにメリットがあるときにだけ例外的に使用する」が僕のポリシーです。ほら、RSpecの（元）メンテナさんもそう言ってるし。 https://t.co/Rp5EiIxCVb #Qiita pic.twitter.com/pMlN35ihEG— Junichi Ito (伊藤淳一) (@jnchito) 2019年5月28日 そもそもの話として、RSpecではsubjectは無理に使わない、というのが僕の持論です。なぜなら無理にを使うと、いびつなテストコードができやすいから。基本はsubjectなしで書く。明らかにsubjectが有効なと
わたしがテスターとして恐れる「慣れ」について - CAT GETTING OUT OF A BAG
ソフトウェアテスト Advent Calendar 2022 - Qiita 19日目の記事です。 はじめに 「慣れ」の違和感に鈍感になっているな、と思うときがあります。失敗の言い訳に「慣れのせい」と思ったり、誰かがそう言うのを聞いたりすると、なんとなく釈然としない気持ちになります。こういった種類の違和感をいちいち表明するのもなんだか面倒になって……というより、仕事中はもっと具体的な問題や課題を大切にしてしまいがちで、つい「まあいいか」となってしまうのです。これはよくないよね。 慣れの違和感の正体 より良い製品をつくるために製品や開発に関する知識や失敗を含む経験は不可欠です。知っていることが増えれば増えるほど、調査や試行錯誤にかかる時間、ゴールに到達するまでの時間を減らせます。製品の細部にまで自分たちの知見（あたたかい血）を巡らせることができます。これはプログラマもテスターもみんなそうです
99bottles of OOP を読んだ - Write Code or Die
オブジェクト指向実践ガイドを書いたSandi Metzの新刊を読んだ。 実は年末くらいには買っていたのだけれども、積ん読してしまっていた。 しかし先週アップデート版が出たというお知らせを受けて（pdf版なのでアップデート版ももらえる）これは読むしかないと思い週末を利用して一気に読み終えた。 内容 OOPを実践する際の指南書。 オブジェクト指向実践ガイドももちろん表題の通りオブジェクト指向について解説していたが、それよりも実践寄りの内容。そして多くのページがリファクタリングについて書かれている。 It turns out that everything you need to know about Object-Oriented Design (OOD) can be learned from the “99 Bottles of Beer” song. という一文から始まる通り、99 bo
ソフトウェアの品質ってなんだろう - >& STDOUT
このブログの主な読者層は「品質保証部」やそれに類する組織に属しておられることと思います。「品質保証部」です。「品質」を「保証」する「部門」です。「品質」を… クドいですね。しかし、みなさんご自身は「品質」、特にソフトウェアにおけるそれを適切に説明することができるでしょうか。そこで今回は、僕自身もソフトウェアテストという仕事にはじめて触れた時に抱いたギモンである「ソフトウェアの品質って何？」について現時点での解を示してみたいと思います。 歴史にあたろう このような大きな概念を知るときは歴史にあたるのが王道です。きっと僕が疑問に思うよりはるか昔から、比べ物にならないぐらいの膨大な時間を掛けて、賢人たちが議論して辿り着いた解が既に存在すると考えるべきです。ただし、広くそれを伝えるために抽象化されているので、明日から現場で使えるほどの具体性を期待するのは筋違いでしょう。ラストワンマイル、現場への
テスト駆動開発 - kagamihogeの日記
昔、自分がどのようにプログラミングをしているか、を文章に書き起こせるか、という話を同僚としたことがある。それで書いてみようとしたのだが、すぐに行き詰った。最大の壁は自分の思考を文章にすることで、文章は基本的に上から順に読む線形の構造になるが、プログラミング時の脳内の思考は（おそらく）そんな単純ではない。他にも、あまり簡単な例にすると一般化されないし、かといって理論に寄り過ぎると実用性が無い……などなど。考え始めると、何をどれだけ書けば良く分からなかったので適当なところで諦めた過去がある。 そこで本書だが、テスト駆動に関する本ではあるものの、実質的には、どのようにプログラミングをすると良いのか、を解説している。数個程度のクラスから構成される機能を作るとき、いかに取り組めば良いのか。あるいは、おおむね一日単位のプログラミングにどのように取り組めば最適なパフォーマンスを発揮できるのか。 正直なと
レガシーコード改善ガイドを読んだ - $shibayu36->blog;
レガシーコード改善ガイド (Object Oriented SELECTION) 作者:マイケル・C・フェザーズ翔泳社Amazon レガシーコード改善ガイドを読んだ。 この本では、レガシーコードの内部をリファクタリングする際に何を気にする必要があるかとか、非常に長いモンスターメソッドをリファクタリングしていく時にまずどこからやるかとか、そういうことが書いてある。とにかくレガシーコードに直面して何から始めたらいいかわからないという時にはおすすめ。 リファクタリングという本と近い内容だけど、僕の中ではこの本よりはリファクタリングの方がなんとなく肌にあった。また今度再読してみようと思う。 印象に残ったところを書いていく。 依存関係を排除する 「たいていの場合、テストの最大の障害となるのが依存関係です」と書いてあるのだけれど、これは確かにと思った。いつもは無意識にやっているけど、言語化されてよかっ
アジャイルテストの4象限とテスト自動化のピラミッド - 野次馬エンジニア道
「アジャイルなプロセスでやっています」といった台詞はよく聞く。しかしテストの重要性や方法論について力説してくれる人は多くない。 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践) 作者: Janet Gregory,Lisa Crispin,榊原彰,増田聡,山腰直樹,石橋正章出版社/メーカー: 翔泳社発売日: 2009/11/28メディア: 大型本購入: 3人 クリック: 142回この商品を含むブログ (53件) を見る これを機に体系的に勉強してみようと手に取った一冊。内容以前に4,800円という価格と一部の翻訳にやや難があるように感じた。誰かもう少し安く読み易い本を出してくれないだろうか。エキスパートな先輩によれば「名著」だそうですが。 この本の特徴は冒頭の p. xxvi より テスト実施とテスト
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
Everyday Rails Testing with RSpecはRSpec初心者～中級者にオススメの一冊！ - give IT a try
2014.2.7 追記: 日本語版を発売しました！ 「この本は英語版しかありません」と書いていましたが、僕自身が日本語版の翻訳し、Leanpubから発売しました。 詳しくはこちらのエントリをご覧下さい。 RSpec初心者必読！「Everyday Rails - RSpecによるRailsテスト入門」を発売しました - give IT a try 正式版公開のお知らせと幻のあとがき・Everyday Rails - RSpecによるRailsテスト入門 - give IT a try はじめに 先日、RSpec関連のこんな電子書籍を買いました。 Everyday Rails Testing with RSpec Kindleに入れて読みました。 RSpecを学習するための書籍としてはなかなか良かったので、今回はこの本の内容を紹介します。 この本を購入した動機 RSpecは仕事でも使っていて、
読書メモ/"How Google Tests Software", 「テストから見えてくるグーグルのソフトウェア開発」 - Glamenv-Septzen.net
ホーム 検索 - ログイン | | ヘルプ 読書メモ/"How Google Tests Software", 「テストから見えてくるグーグルのソフトウェア開発」 [ Prev ] [ Next ] [ 読書 ] 邦題：「テストから見えてくるグーグルのソフトウェア開発」 ・テスト技術者、およびTDD(テスト駆動開発)やテストファーストに意欲的に取り組んでいるエンジニア向けに３行でまとめる。 1. グーグルですら適切で合理的なテストケースの作成やテスト計画、テストの自動化、そして開発者にテストコードを書かせるのに苦労している。昔も、今も、そしてこれからも。 2. だから、テストやその自動化には「正解」なんて無い。グーグルですらそんなの知らない。だからグーグルではテストに対して様々な実験や検証が日常的に行われ、そこからイノベーションが生まれる。 3. では何を軸とするか？それはひたすら、「テ
「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない」 - カレーなる辛口Javaな加齢日記
注：テスト本リストは加筆修正した上で，改めて独立した項目に作り直した． → http://d.hatena.ne.jp/JavaBlack/20150926/p1 http://www.publickey1.jp/blog/12/8585.html http://www.keyman.or.jp/at/dev/debug/30004610/ 数値の正確さはともかく，だいたいそんなもんでしょう． 「スキルがないからPHP使ってます」「Javaは使ってるけどオブジェクト指向って何ですか？」みたいな現場だと，テストするスキルも人手も足りない． そもそもテストを知らない．テスト＝手動テストだと思っている． デバッグといえばデバッガでするものだと思っている． 導入するメリットが理解できない． テストをする人に，プログラミングのスキルや経験がない．ひどい場合には素質が無い．*1 導入するスキルがない．
アジャイルサムライ読み終わった | 自転車で通勤しましょ♪ブログ
アジャイルサムライ読み終わった。テクニック以外の部分（いわゆる取り組み方）が重要なのは当然として、取り組み易い環境作りが大事。人は怠け者だから、取り組み易い環境がないとやっぱりうまくいかない。所詮は理想と思って取り組めなくなってしまう。 アジャイル開発をするのに重要な以下の4つ。 ユニットテスト リファクタリング テスト駆動開発 継続的インテグレーション どれも個人的な開発ではおざなりにしてまいがちな項目…。 これらの環境整備をまず行なっていきたい。 これらがひいては時間の節約をするための強力なツールになるので、事前に投資するべき。 プロジェクトの回し方については、アジャイルな見積りと計画作りに書かれていたように、イテレーションの中でベロシティ（チームの開発力）を計測しつづけて、チケットに当てられたポイントをベロシティxイテレーションで差し引くことでプロジェクト完了時期を算出するという方法
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
xUnit Test Patterns: Refactoring Test Code: Gerard Meszaros: 0076092037590: Amazon.com: Books
達人プログラマー読書会@札幌-2011.11.28 に参加しました – 寺子屋未満