Testing Web APIs は想像したAPIテストのテクニック集以上の本でした
タイトルからREST APIのテスト技法や実装方法が中心の内容かと想像していましたが全12章に渡って、「ちゃんとプロダクトを理解し、計画を立ててから機能・非機能双方でAPIに対するテストを行う」という包括的な内容で良い意味で驚きました。 特にテスト計画に時間をかけすぎずに整理する考えや、 Explore It! という探索的テストの本を参照しながら、何をテストするか整理する方法は具体的なHowに寄りすぎず、非常によかったです。 心に残ったポイントの紹介 ここからは書籍を読んで特に私の心に残ったことを紹介します。 Chapter 2: Beginning our testing journey 本書の第2章では、APIテストを始める前の重要なステップとして「プロダクトを深く理解すること」が強調されています。 The more we learn, the clearer our strateg
「単体テストの考え方/使い方」で学んだこと - 徒然なるままに
この本を読んだので学んだこと記載します。 単体テストの考え方/使い方 | マイナビブックス 読んだ理由 感想 学びになったこと(抜粋) テストケースの質 単体テストにおける古典学派とロンドン学派の違い 単体テストの定義(古典学派) 単体テストの定義(ロンドン学派) 良いテストを構成する4本の柱 ブラックボックステストとホワイトボックステスト 4種類のプロダクションコード 統合テストについて 疑問点 読んだ理由 この本は去年の12月年末くらいにtwitterで流れてきて知りました。単体テストがどのような役割を果たせるのか改めて学べそう、そして、効果的な単体テストを学べそうと思ったので読んでみました。 感想 分厚い本ですごく読み応えがありました。読むのが少し大変でしたが、その分学びになったことが多かったです！ 古典学派とロンドン学派の考え方、初めて知りましたが面白かったです。この本は古典学派推
RSpecによるRailsテスト入門を読んで - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回はRSpecによるRailsテスト入門という本を読んだので、そちらの感想を書いていこうと思います！ 今回読んだ本はこちらです。 良かったところ RailsやRubyの書籍はたくさん存在していますが、自動テスト（RSpec）についての日本語の書籍はなかなか見たことがありませんでした。よくRailsの書籍の最後の方に少しだけのっていたり、動画の中で少し触れていたりというものはありますが、ガッツリテストの本って見かけないのでテストの学習をしたい方にはとても良いと思いました。 悪かったところ テストって結構簡単に書けると思われてい
xUnit Test Patternsから学ぶ12個のユニットテストの原則 - Qiita
本エントリは、xUnit Test Patterns: Refactoring Test Codeという書籍の「Chapter5 Principles of Test Automation」の内容をベースに、12個のユニットテスト原則についてまとめていきます。この書籍は、2007年に販売されたものですが、今でも十分役に立つユニットテストに関する原則を伝えています。 ウェブでは、次のURLでも内容を見ることができます。 自動ユニットテストの原則 ここで紹介されるものは、ユニットテストで確認したい quality のリストです。ですので、直接適用する「パターン」ではありません。 「何をやるか」よりも「なぜやるのか」という観点においてまとめられています。 本エントリでは、xUnit Test Patterns: Refactoring Test Codeで紹介されている12個の原則をベースに、ほ
UnitTestを書く上で注意すべきこと - Qiita
※ 時折こぼけを挟んでおります。 UnitTestを書く上で注意すべきこと 誰に向けた記事か プログラミングは基本的に行える(2~3年程の経験) まだアーキテクチャについては良く分かってない つまり私 モチベーション クリーンアーキテクチャ 238p から引用 テスト容易性のための設計 システムと強く結合したテストは、システムに合わせて変化する必要がある。システムコンポーネントに対する小さな変更であっても、結合した多くのシステムが壊れたり、変更が必要になったりする。中略。共通のシステムコンポーネントを変更すると、何百や何千というテストが壊れる可能性がある。これは、脆弱なテストの問題（Fragile Tests Problem）と呼ばれている。 脆弱なテストは、システムを硬直化させるという悪影響を及ぼす。システムを少し変更しただけで大量のテストが失敗するとなると、開発者は変更するのをためらう
【Rails/RSpec】Everyday Rails - RSpecによるRailsテスト入門の要約/感想 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回はRSpecの技術書であるEveryday Rails - RSpecによるRailsテスト入門を読了したので、その要約と感想について書いていければと思います。 RSpecとは？ ruby用に開発された、テスト用の フレームワーク のことです。 RSpecを用いることで、少ない記述で、可読性に優れたコードを簡単に記述することができます。 本記事の対象者 railsのチュートリアルレベルを一通り学び終え、テストコードの学習を始めようと思っている方 これから Everyday Rails - RSpecによるRailsテスト入
フロントエンド開発のためのテスト入門書評
はじめにlink 2023/04/24に発売された「フロントエンド開発のためのテスト入門」を読了したので、読みながらとったメモをもとに感想や自分の考えと違ったところなどをまとめる。 Amazon 全体的に非常に参考になる内容が多いが、特に後半にいくにつれて加速度的に参考になる内容が増え非常に良著であると感じた。 実践Node.js入門でもテストはある程度量をとって記述しているが、テストそのものがメインではないため情報や考え方として落ちている内容の多くがこの本で補完されている。自著を読んだ人には同時に本書もおすすめしていこうと思っている。 Amazon 自分はフロントエンドのテストはバックエンドに比べて優先度が低くなる傾向にある。 これは自分が扱うサービスがtoB系が多く、表示崩れなどがサービス継続上致命的になりにくいため、気づいたベースで最速で直せる環境があればよいと考えているため。 また
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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「テスト駆動開発」を読んだ違和感 私は社内でテスト駆動を布教してしまう程度には、テスト駆動が好きです。そのため、ことあるごとに色んな人にテスト駆動開発の本を勧めているのですが、テスト駆動開発には独特の読みにくさがあります。 その"読みにくさ"というのは、どういうことなのか？KentBeckのテスト駆動開発は、3部から構成されています。 第1部 多国通貨 第2部 xUnit 第3部 テスト駆動開発のパターン 第1部の「多国通貨」はテスト駆動の入門の章です。ドルやフランなど複数の通貨単位を相互に変換したり、足し算や、掛け算を行うロジックを、
『単体テストの考え方/使い方』を読んで現実的なテスト駆動エンプラ開発を考えよう - 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 より テスト実施とテスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
