ABCEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAF

■参考 ・JSTQB ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 ・業務でも活用できるソフトウェアテストの7原則 ・Agile Testingのエッセンス ・TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング ・テスト駆動開発 ・BDDとATDD ・The BDD Books - Discovery (Japanese Edition) ・リーダブルテストコード ・テストコードにはテストの意図を込めよう ・組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） ・質とスピード（2022春版、質疑応答用資料付き） ・【翻訳記事】テストに対する考え方「Testing Manifesto」 ・マネジメント向けアジャイル開発概要 ・The Software Testing Ice Cream Cone ・Goo

この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ

レガシーコード改善勉強会 in Yahoo Japan 2014.09.27 プロジェクトに対する方法論構築と、タスクマネジメントについての紹介 後半はMikado Methodの簡易紹介です。

はじめに Mockeryのケーススタディをつらつらと書いていきます。 こういうケースでは、このようにコードを書いたら良さげ　というように書いていきます。 日本語で書かれてるドキュメントがあります。感謝しかない。 クラスAのテストをしたいけど、クラスAはクラスBに依存してて、クラスBの影響を受けたくない よくあるパターンですね。 クラスAはクラスBに依存している。（クラスAはクラスBが無いと動かない） クラスAの単体テストを書きたいので、クラスBがうまく動いてなくてもクラスAのテストに影響を与えたくない。 サンプルコード class A { private $classB; public function __construct(B $classB) { $this->classB = $classB; } /** * foobarを取得する * * @return string */ pu

はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの？どんなテストを書いたらいいの？と迷っている初心者プログラマさんは意外と多いのではないでしょうか？ そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 本来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と

テストコードは重要なものです。対象のコードの品質を担保してくれるばかりでなく、自動テストによって改修時のバグ発生を未然に防いだり、リグレッションテストの手助けにもなるでしょう。 反面、テストコードの作成には、それなりの工数が掛かることも周知のとおりですから、工数をかけたくないプロジェクトでは後回しにされてしまいがちです。 テストコードとは メソッドなどの実行結果が適切かどうかをコード上で試験するものです。以下に例を挙げてみましょう。 例は２つの引数を合計する単純なコードです。 public int sum(int a, int b) { return a + b; } これに対してテストコードを書いてみます。jUnitのメソッドを使ってみましょう。 public void testSum() { int result = sum(1,2); assertEquals(result, 3);

ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発慎一 古賀

[db tech showcase Tokyo 2014] B25: [In-Memory DB: SAP HANA] 障害・災害対策のメカニズム by...Insight Technology, Inc.

こんにちは、技術広報のyayawowoです。 「自動化（オートメーション／Automation）」 今、この言葉を聞いて胸がときめいた方に必見です！ 当社主催イベントでも人気の高い 「自動化大好きエンジニアLT会」全5開催分の資料をまとめて紹介します！ イベント詳細はこちらをご確認ください！ ・自動化大好きエンジニアLT会 ・自動化大好きエンジニアLT会 - vol.2 ・自動化大好きエンジニアLT会 - vol.3 ・自動化大好きエンジニアLT会 - vol.4 ・自動化大好きエンジニアLT会 - vol.5 目次 目次 手動テストやインフラ構築は自動化しよう APIテスト品質を向上させる Datadog Synthetic Monitoring APIテスト自動化とテストピラミッド TestLinkにテスト結果を自動的に登録 Cypressでサクッと始めるE2Eテスト 自動テスト環境を

はじめに みなさん、Playwright をご存知ですか？ これまで、Node.js での E2E テストといえば、puppeteer、TestCafe を使っていたという方も少なくないのではないでしょうか？ Playwright は、そのうち、puppeteer と同じような記述も多く、非常に分かりやすいかと思います。 また、Microsoft によって開発、運用されているため、今後サポートされなくなるというリスクも ある程度回避できるかと思います。 2020/12/26 時点では、バージョン 1.7.0 なので、その時点での情報になります。 サポート環境 2020/12/26 時点でサポートしているのは以下になります。 Node.js 10.17 以上 Windows: Windows 及び WSL で動きます macOS: 10.14 以上 Linux: ディストリビューションによる

この10年は多くの変化がありました。 ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。 技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。 一方で、テストや品質保証はどのように変わってきたでしょうか？ 私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX（デジタルトランスフォーメーション）」の影響か、 開発に速さがより求められるようになってきたように感じています。 そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。 このセッションでは、アジャイル・DevOps時代におけるテストと品質について、 - 現在 - 戦略と戦術 - 組織未来 のお話させていた

組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ～テスト駆動開発について～ 4.深めつつ広げる鍵 ～ペアプログラミングについて～ 5.見る夢について

この記事の対象読者 Webフロントエンドのテストコードを雰囲気で書いてる人 この記事の前提 テストフレームワークは Jest の利用を想定しています Jest自体のセットアップや使い方は一切触れていません フロントエンドテスト、慣れてないとハマりがち 経験上、フロントエンドのテストコードを書く際には、慣れていないとハマったり混乱してしまうポイントが多くあると思っています。 僕のdivタグ書き換えるコードがテストだと動かない エラーになるテストなのにパスしちゃう 慣れてくると何でもない部分ではありますが、基本的な考え方や躓きやすい箇所を整理してみました。 フロントエンドのテストコードはNode.js上で実行される フロントエンド開発では、実行環境として主にブラウザを対象とすることが多いでしょう。つまりWindowオブジェクトの利用やDOM操作が可能です。（たとえば location.href

この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回

「現場で役立つシステム設計の原則」を読み終わって、今は「レガシーコードからの脱却」を読んでいる途中。 先日のEOF2019であったt_wadaさんの「質とスピード」、ryuzeeさんの「レガシーコードからの脱却」の資料も合わせて読むと理解が深まってくる。 speakerdeck.com slide.meguro.ryuzee.com 内部品質であるソフトウェアの保守性を高めること t_wadaさんの「質とスピード」スライドより t_wadaさんの「質とスピード」スライドより 最初から作るべきものが正しく予測できて、それを一発本番の開発フローで正しく作ることが「幻想であること」がもう分かってきたので、最近はアジャイル開発がキャズムを超えてきている。 当てになりにくい「予測」よりも「対応」（=変更容易性=適応性）を高めるプラクティスが重要になってきていて、テスト自動化やドメイン駆動、モブプロな