PHPカンファレンス小田原2024での発表資料です https://fortee.jp/phpconodawara-2024/proposal/4d39c7ef-058c-4648-b1d7-5510497e0d81
[beta] APIシナリオテストとは？ 複数のAPIを連鎖的に呼び出し（Chaining Requests）て実行するテストのことです。 例えばユーザーの新規登録後に更新させるケースでレスポンス（ユーザーID）を次のAPIのパラメータとし て引き継ぎながらAPIを呼び出すテスト。 1. ユーザー新規登録（Create User） curl -X 'POST' \ 'https://example.com/api/v3/user' \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "username": "newUser", "firstName": "John", "lastName": "James", "email": "[email protected]", "password
ブラウザの自動操作にPuppeteerを利用しているが、試しにPlaywrightを使ってみたら良いと思う点が多かったのでまとめた。正直な感想を言うと、「ほぼ上位互換では？」と思うくらいには良い点が多かったし、悪い点は見つからなかった。同じ作者の後発なだけはある。 なお、Puppeteer歴1年、Playwright歴1日で書いているので、変な箇所があればご指摘ください。 利用バージョン Puppeteer : 5.5.0 5.4.1 Playwright : 1.8.0 便利だと思った点 とても柔軟なselector Puppeteerはpage.$x()など一部でXPath selector が利用できるものの、page.click()やpage.$eval()など多くの関数ではCSS selectorしか利用できなかった。 しかし、Playwrightでは、selectorを利用する
Dependency Injectionパターンを用いたクラスのテストコードを記述しているとき、Injectionする対象が増えた際、修正が広範に及んでしまう事があります。 このとき、依存オブジェクトを注入して生成するFactoryクラスを利用してテスト対象のクラスを生成することで解決ができます。 背景 次のClientのようなテスト対象のクラスが存在したとします。 public class Client { private IFooServer FooServer { get; } public Client(IFooServer fooServer) { FooServer = fooServer; } public void Foo() { FooServer.FooService(); } } public interface IFooServer { void FooServic
はじめに あなたは現在開発中のRailsアプリケーションでUserを削除する機能をテストしたいとします。 このアプリケーションではUser一覧画面に表示されている"Destroy"リンクをクリックすると、Userを削除できます。 ↓ そこであなたはRSpecで次のようなテストコード（システムスペック）を書きました。 RSpec.describe "Users", type: :system do let!(:user) { User.create! name: 'Alice' } example 'Delete user' do visit users_path # 削除前には"Alice"が表示されている expect(page).to have_content 'Alice' # 削除を実行する click_link 'Destroy' # 削除が完了すると"Alice"は画面に表示さ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 プロダクト開発を行う上で、テストコードは重要な要素であるかと思います。 ユニットテストコードを書くことで、クラス単位の動作保証を行うことが出来ます。また、E2Eテストやインテグレーションテストを書くことで、DBアクセスや外部連携を含めた、プロダクトにおける一気通貫の動作を確認することが可能になります。 作成したテストコードは、CICDと組み合わせて、自動テストとして定期的に実行させます。これにより、既存のソースコードを変更した際の品質を (ある一定レベルにおいてですが) 担保することが出来るようになります。結果として、開発メンバー
「テスト 書くべき」って検索すると玉石混交な記事がわんさか出てくるのですが、そもそもなんでこういった議論は常に紛糾するのでしょうか？ 僕個人としては、テストコードというものへの捉え方はその現場の思想に密に依存しており、その前提を明示しないまま議論を進めると、「スピード感」「技術者の習熟度」「自社開発か否か」などの様々な変数の違いによって意見が食い違い、容易に銃弾飛び交う戦場と化す、と考えています。 そのため、この議論を始めるのは下手をするとパンドラの箱をパカっと開けて、収集つかないことになるのかなーと思っています。 僕の置かれている前提ということで、流れ弾で死にたくないのでまず僕の前提を明らかにします。 個人的な趣味趣向の話まず個人的な立場を表明しておきますが、僕は書くまでは、億劫なんだけど書き始めたら割と好きで黙々と書いていたくなるタイプです。かといって、仕様がピョンピョン変わる現場での
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※個人の見解です。所属する組織の意見を代表するものではありません。 未整理だけど一旦投下。 なぜ自動テストなのか（見えているゴール） よい自動テストはプロダクトの健康に大きく寄与する プロダクトの健康は開発者を変更の恐ろしさから解放する よい自動テストはシステムの継続的な運用コスト削減に寄与する 今更なに言ってんの？という話だが、固い組織の現状認識は想像を絶する たくさんの壁がある 個人の壁 「自動テストなんて書いたことありません」 「妙な仕事増やさないでよ…」 組織の壁 「そもそもユニットテストなんて書いたら、大幅に工数増えるじゃん。
チョコレート対バニラTDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。 詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。 詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか？ これでは埒が明かない。 原則一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。 詳細で論争するよりも、原則で論争したほうが生産
ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか？という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は本当に有効なのか？組み合わせテスト技法と上手に付き合う方法 ｜ DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか？条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I
まとめJavaScript の callback メソッドを testable にしたい。 testable にするには独立して呼べることが大事。つまり独立メソッドにし、名前をつけることが必要。独立メソッドを callback として渡すにはリファレンスにするリファレンスとして渡されたものは実行時に this が決定するのでそのまま実行すると同じ class 内でも this を見失うリファレンスを bind(this) しておこう例
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
うちのチームのプログラマーはテストが好きかどうかは分からないけど「これよく見つけたなー」と思うようなバグを見つけてくるからテストがうまいと思う。で、なんでうまいのか考えているのだけど「毎日１時間、システムレベルのテストをしている」のが、うまくなる要因の一つなんじゃないか。— miwa (@miwa719) 2019年6月24日 医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。いろんなチームに所属し、多くの開発者と一緒に仕事してきましたが、現在所属しているチーム（うちのチーム）のプログラマーはテストがうまいです。プログラマー時代の自分と比較してもそう思いますし、『ソフトウェアテスト』という側面から製品開発を考えられるようになった今の自分から見てもそう思います。いいバグを見つけたなぁ…（素晴らしい）と思うことが多々あります。 うちのチームのプログラマーはなぜテスト
本エントリは、xUnit Test Patterns: Refactoring Test Codeという書籍の「Chapter5 Principles of Test Automation」の内容をベースに、12個のユニットテスト原則についてまとめていきます。この書籍は、2007年に販売されたものですが、今でも十分役に立つユニットテストに関する原則を伝えています。 ウェブでは、次のURLでも内容を見ることができます。 自動ユニットテストの原則 ここで紹介されるものは、ユニットテストで確認したい quality のリストです。ですので、直接適用する「パターン」ではありません。 「何をやるか」よりも「なぜやるのか」という観点においてまとめられています。 本エントリでは、xUnit Test Patterns: Refactoring Test Codeで紹介されている12個の原則をベースに、ほ
良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。 ぼくは、 EoT(*1)の高い設計が、よいオブジェクト指向設計である。 と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、
![「テストしやすい」ことが、良い設計(EoT=Ease of Testing) - An Agile Way [ITmedia オルタナティブ・ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/940258f08a8861f663a305f5e532f8d8c90667bb/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fblogs.itmedia.co.jp%2Fmt-static%2Fsupport%2Fassets_c%2Fuserpics%2Fuserpic-20-100x100.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
