並び順

ブックマーク数

期間指定

  • から
  • まで

721 - 760 件 / 762件

新着順 人気順

testingの検索結果721 - 760 件 / 762件

  • Migrating 500+ tests from Mocha to Node.js | Astro

    Over a month ago, we discussed a possible migration to the Node.js test runner. While we were sufficiently happy with Mocha, we are always looking to make our CI jobs faster. Relying on a test runner baked inside our runtime had some advantages for our main monorepo: Two fewer dependencies to install and maintain in our monorepo: mocha and chai. Maintainability: there are more people involved in t

      Migrating 500+ tests from Mocha to Node.js | Astro
    • GitHub - pashak09/ts-expect-error-validator: Command-line tool to validate expected TypeScript errors

      You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

        GitHub - pashak09/ts-expect-error-validator: Command-line tool to validate expected TypeScript errors
      • Netflixは、フロントエンドテストへのカスタムアプローチであるSafeTestを発表

        Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

          Netflixは、フロントエンドテストへのカスタムアプローチであるSafeTestを発表
        • ChatGPTでE2Eテストコード自動作成 | フューチャー技術ブログ

          9/7に行われた技育CAMPアカデミアというイベントでPlaywrightについて話をしてきました。テストというと、設計手法であるところのテスト駆動開発は別としてちょっと業務っぽい感じがして学生さんにはちょっと響かないかな、というのも心配でしたが、アンケートを見る限り、わかりやすかったという声も多くてほっとしました。 次のスライドが今回の資料です。スライドの内容の多くはPlaywright連載始まりますに掲載されている記事にもぼつぼつある内容も多い(APIテストはないですが)のですが、本エントリーでは発表の最後に触れたChatGPTなどの生成AIを使ったE2Eテストの生成について説明していきます。 ChatGPTが話題を席巻してしばらく経ちます。とはいえ、内製開発での利用以外はソースコード開発にばりばり使う、みたいな宣言はあまり聞かない気がします。利用を制限している会社も数多くあります。

            ChatGPTでE2Eテストコード自動作成 | フューチャー技術ブログ
          • オブジェクト指向で書く!テストのしやすいプログラム

            概要 関数の組み合わせで作られているテストしにくいプログラムから、オブジェクト指向で書かれたテストのしやすいプログラムにリファクタリングを行う中で、クラスを用いてプログラムを書くとどのような嬉しいことがあるのかについて説明させていただければと思います。 今回使用したソースコードなどは以下に置いてあります。ご自分で実行しながら読まれても面白いかもしれないです。 想定読者 オブジェクト指向について、聞いたことはあるけどイマイチピンとこない ソースコードに単体テストを入れようとしてるけど、具体的にどのように入れればいいのかわからない いまいちクラスを用いてプログラムを書くことの利点がわからない クラスがどのようなもの何かについては理解している 前提としている知識 単体テストの基本的な考え方 TypeScript(ご自身の得意とされている言語にも同じような機能はあるはずですので適宜読み替えていただ

              オブジェクト指向で書く!テストのしやすいプログラム
            • 【Flutter】Flutteristの為のMaestro入門

              Maestroとは? 以下のような特徴を持つモバイル用のE2Eテストフレームワークです。 2022年9月にリリース yamlベースでテストケースを記述 Flutterに対応 CI/CDへの組み込みもローカルでの実行も可能 2022年9月にリリースされたばかりでまだ未成熟な部分も多いかもしれませんが、Flutterにも対応されており、非常に開発体験が良いので、今後に期待も込めて使い方を整理していきたいと思います。 以下にサンプルコードも用意したので参考になれば幸いです 💫 始め方 1. Maestroをcurlでダウンロード&インストール

                【Flutter】Flutteristの為のMaestro入門
              • チームで学ぶTDD輪読会 - コドモン Product Team Blog

                こちらはコドモン Advent Calendar 2023の11日目の記事です🎅 qiita.com こんにちは!コドモンプロダクト開発部の村松です。 コドモンでは1週間につき半日、業務時間を自己学習に使える0.5投資制度があります。 今回は0.5投資制度を使い、チーム内で行ったTDDの輪読会について紹介します! 輪読会スタートの背景 輪読会の進め方 輪読会のメリット チームでの変化 テストを先に書くのが当たり前に 小さくテストし、開発サイクルを回す意識 問題の言語化と改善 todoリストの活用 おわりに 輪読会スタートの背景 コドモンでは以前、t_wadaさんにレガシーコード改善ワークショップを行っていただきました。 tech.codmon.com ワークショップをきっかけにTDDへの関心がチーム内でも高まったので、今回の輪読会はTDDをテーマにスタートしました。 輪読会の進め方 輪読

                  チームで学ぶTDD輪読会 - コドモン Product Team Blog
                • どこまでユニットテストを書くべきかについて、現時点・現在地での考察 - Qiita

                  はじめに 最近私が所属しているチームで、新たに追加したメソッドにユニットテストを書くべきか、書くならどこまで、どう書くべきかという議論が起こりました。 そのことについて私個人・現時点・現在地でどうすればよいのかを考えたので、言語化しておこうと思います。 先に現時点・現在地での結論 チームが持っているソースコードと、今いるメンバーによります(そりゃそうだ)。 少なくとも弊チームでは、書けるところには全部書くつもりで臨むべきだと思っています。 前提 Javaで記載されたソースコードににおけるユニットテストに関する議論です。 Java8 JUnit5 弊チームの現状 弊チームが担当している製品、その中のサブシステムのソースコードには、ユニットテストが書かれていない箇所のほうが多い この1年でユニットテストを書き始めたメンバーが多数 私自身もユニットテストを書き始めてから1年ちょっと経ったところ

                    どこまでユニットテストを書くべきかについて、現時点・現在地での考察 - Qiita
                  • DockertestとLocalStackを使って 外部サービスに依存した多要素認証の 動作確認・テストをした話 / A story about using Dockertest and LocalStack to check and test the operation of multi-factor authentication that depends on external services

                    2024/06/08: Go Conference 2024 https://gocon.jp/2024/ DockertestとLocalStackを使って 外部サービスに依存した多要素認証の 動作確認・テストをした話 西田 智朗 ソフトウェアエンジニア

                      DockertestとLocalStackを使って 外部サービスに依存した多要素認証の 動作確認・テストをした話 / A story about using Dockertest and LocalStack to check and test the operation of multi-factor authentication that depends on external services
                    • [アップデート]AWS SAM CLIでAWS環境上のLambda関数のテストイベントを操作できるようになりました | DevelopersIO

                      初めに 本日AWS SAM CLI v1.98.0がリリースされました。 今回のアップデートではsam remoteコマンドに新たなサブコマンドtest-eventが追加されSAM経由でAWS環境上のLambda関数のテストイベントを操作できるようになります。 また合わせてsam remote invokeコマンドに新たなオプション--test-event-nameが追加されAWS環境上に設置されているイベントデータを使えるようになっております。 remote invokeコマンドについては今年の6月ごろのアップデート追加されたサブコマンドでSAMを通してローカルではなく実際のAWS環境上のLambda関数を実行できる機能となります。 以前はsam remote invokeは実際にデプロイされたAWS環境上の関数を呼び出すことができたのですがテストイベントは取り扱うことができず、イベント

                        [アップデート]AWS SAM CLIでAWS環境上のLambda関数のテストイベントを操作できるようになりました | DevelopersIO
                      • Trace-based Testingというアイデアに感動した | Marginalia

                        先日、Trace-based Testingなるテスト技法についてのブログを読んで感動した。(感動しただけでまだ試してはいない。) 何に感動したかというと、トレースによってシステムの振る舞いをテストするというアイデアは、僕がPHPカンファレンス福岡で発表したテストについての基本的な考え方とこの上なくマッチしていて、なおかつ具体的な技法としてトレースをテストに使うという発想は僕の中になかったからだ。あっぱれという感じだ。 PHPカンファレンス福岡では、テストの本質は開発者が安心を得るためのプロセスであり、したがって、「このテストが通るなら本番でも期待通りに動作するはずだ」と思えるようなテストが、テストとしてのパフォーマンスが高いと話した。 Trace-based Testingがもっともよく機能するのは、開発者がデプロイ後にシステムの正常動作を検証するために最も信頼しているものがトレースであ

                          Trace-based Testingというアイデアに感動した | Marginalia
                        • 開発者を解き放て! Postmanが目指すAPIファーストな開発モデル 〜APIエコノミー、生成AI活用、開発の民主化まで

                          開発者を解き放て! Postmanが目指すAPIファーストな開発モデル 〜APIエコノミー、生成AI活用、開発の民主化まで 2023年12月5日、開発者向けAPIプラットフォームを提供するPostmanは「日本上陸記念イベント」を開催し、日本市場への本格的な参入を発表した。本記事では、Postman創業者 アビナフ・アシュタナ氏と、ウルシステムズ株式会社 漆原 茂氏の講演レポートを中心に、Postmanが目指すAPIファーストな世界観と、開発者にもたらされる変化について紹介する。 日本でも活発なコミュニティを オープニングでは、Postman株式会社 代表取締役社長 平林 良昭氏から、日本市場とコミュニティの概況について紹介された。 2014年にインドで創業したPostmanは、APIの構築・管理・テストのための開発者プラットフォームだ。2017年にアメリカに拠点を移し、2023年4月に日

                            開発者を解き放て! Postmanが目指すAPIファーストな開発モデル 〜APIエコノミー、生成AI活用、開発の民主化まで
                          • APIの自動テストとモックAPIを駆使してTDD風に開発する

                            こんにちは、バックエンドを中心に開発をしている野島と申します。 最近下記の流れで開発をしており、とても開発しやすいと感じているので共有します。 APIの自動テストの作成 モックAPIの作成 APIの処理の実装 TDDは下記の順序で行いますが、それを拡張してAPI開発にあてはめたようなスタイルです。 レッド:動作しない、おそらく最初のうちはコンパイルも通らないテストを1つ書く。 グリーン:そのテストを迅速に動作させる。このステップでは罪を犯してもよい。 リファクタリング:テストを通すために発生した重複をすべて除去する。 テスト駆動開発 p.ⅹより引用。 それでは、内容に入っていきます。 0. 前提 Go言語でAPI開発し、テストツールにはscenarigoを利用するとします。 scenarigo は YAML でテストシナリオを記述するAPIテストツールです。簡潔に記載できるので、どのような

                              APIの自動テストとモックAPIを駆使してTDD風に開発する
                            • https://www.juse.jp/sqip/symposium/2023/timetable/files/B3-2_happyou.pdf

                              • E2EテストのためのFlutterアプリ実装ガイドライン | MagicPod: AIテスト自動化プラットフォーム

                                本ガイドラインについて このページでは、「E2EテストのためのFlutterアプリ実装ガイドライン」をダウンロードできます。(登録不要、無料) このガイドラインに準拠してFlutterアプリを作成することで、AppiumやAppiumを内部で利用するE2Eテスト自動化ツールでアプリのテストを自動化できるようになります。 「E2EテストのためのFlutterアプリ実装ガイドライン」(2023年7月31日版)のダウンロード

                                  E2EテストのためのFlutterアプリ実装ガイドライン | MagicPod: AIテスト自動化プラットフォーム
                                • ナレッジワークで取り組んでいるバグ分析の紹介|Knowledge Work Developers blog

                                  ナレッジワークQAエンジニアの岡崎(@rabbit_tail14)です。 ナレッジワークでは、プロダクト開発における初期品質およびアジリティを高めるための取り組みとしてバグ分析を行っています。 この記事では、実際に計測しているメトリクスや、どのように運用しているのかなど、できるだけ具体的に記載していきますので、バグを資産として活用したいと思っている方や、既に活用しているが他社の事例も知りたいと考えている方などの参考になれば幸いです。 バグ分析を始めた背景と目的バグ分析に取り組む前の状況私は2022年3月にナレッジワークに入社したのですが、当時はまだバグ分析は実施されておらず、対応完了後にバグチケットを見返すことはほとんど行われていませんでした。 そのため、なぜバグが埋め込まれたのかは基本的に対応者しか把握しておらず、個人の知見にしかなっていない状況でした。 一方で、よく耳にするようなデグレ

                                    ナレッジワークで取り組んでいるバグ分析の紹介|Knowledge Work Developers blog
                                  • MagicPodの自動テストの結果入力を自動化しました - Gunosy Tech Blog

                                    こんにちは。QAチームのmiyagiです。 QAチームで活用しているテスト自動化ツール「MagicPod」と、テスト管理ツール「TestRail」を連携させ、自動テストの結果入力をJenkinsで自動化しました。 この記事では、連携に必要な環境構築や手順について紹介します。 Jenkins MagicPodとTestRailについて 自動化の手順 実行するテストケースとテスト実行設定の準備 PythonスクリプトとAPI利用の準備 APIキーの発行 Pythonスクリプトのカスタマイズ Jenkinsの準備 Jenkinsのパイプラインの設定 実行した結果 Jenkins MagicPod TestRail まとめ MagicPodとTestRailについて MagicPodはUIテスト自動化ツールで、Gunosyでは回帰テストの一部を自動化して実行しています。テスト管理ツールであるTes

                                      MagicPodの自動テストの結果入力を自動化しました - Gunosy Tech Blog
                                    • Improved Cloudflare Workers testing via Vitest and workerd

                                      Improved Cloudflare Workers testing via Vitest and workerd03/15/2024 This post is also available in Español. Today, we’re excited to announce a new Workers Vitest integration - allowing you to write unit and integration tests via the popular testing framework, Vitest, that execute directly in our runtime, workerd! This integration provides you with the ability to test anything related to your Work

                                        Improved Cloudflare Workers testing via Vitest and workerd
                                      • QAメンバーである私は「コードレビュー」でなにを見ているか|tarappo

                                        私は品質管理部の部長をしつつ、開発チームの中で品管メンバーとして動いています。 その中で私が入っている「お会計チーム」でどういったことをおこなっているかを次のブログに書きました。 お会計チームの扱っているものの特性もあり、主にSETスキルを活用しながら案件をリリースまで進めています。 上記の記事に書いているのですが、私がおこなっていることの流れとして(大まかに書くと)次のようなことをおこなっています。 (1)仕様の把握、対応するコードのレビュー (2)上記を元にどのように守っていくかを考えていく この中で「コードレビュー」としてどういったことをおこなっているのかについてあまり書いていないなと思ったので、もう少し詳しく書いてみようかと思います。 なお、今は運用コストなどを考えて、(一般的に言われる)E2Eテストは導入していません。 なので、後述する話で出てくるテストコードは全てそれを除くテス

                                          QAメンバーである私は「コードレビュー」でなにを見ているか|tarappo
                                        • How to Determine OKRs for Software Quality Assurance

                                          Image by DALL·E 3When you come across the terms ‘Software Quality Assurance’ or ‘Application Tester’, what immediately comes to mind is probably someone who is responsible for ensuring there are no bugs in an application. While this is true, but have you ever wondered about the ins and outs of their goals? What specific targets do they need to achieve? How they measure it? Let’s explore and delve

                                            How to Determine OKRs for Software Quality Assurance
                                          • GitHub - stepful/cyperful: Interactive system testing UI for capybara

                                            You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                              GitHub - stepful/cyperful: Interactive system testing UI for capybara
                                            • 開発生産性を3ヶ月で劇的に向上させた取り組み|鈴木啓太

                                              こんにちは、amptalk 株式会社 CTO の鈴木です。 今月で amptalk は5期目を迎えました。GW 明けの8日に全社 kickoff を行い、各組織の前期振り返りと今期の共有方針を行いました。私も開発組織の生産性向上に関する取り組みを紹介したのですが、社内に留めておくのは勿体無い内容なためこちらの note で紹介します。 FY24 Q1 Kickoff Four Keys について私たちの開発組織では、開発生産性を測る指標の1つとして Four Keys を計測しています。Four Keys の詳しい説明は Google Cloud blog の記事がわかりやすいです。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率 - デプロイが原因で本番環境で障害が発生する割合(%) サービ

                                                開発生産性を3ヶ月で劇的に向上させた取り組み|鈴木啓太
                                              • Testcontainersを使ってテストを効率化しよう - 電通総研 テックブログ

                                                こんにちは、Xイノベーション本部ソフトウェアデザインセンターの中村です。 本記事は電通国際情報サービス Advent Calendar 2023の12月8日の記事です。 皆さんはデータベースアクセスを行うアプリケーションのユニットテストやインテグレーションテストをどのように実施していますか?絶対の正解はありませんが、テストの効率性や正確性などを考慮して様々な工夫や検討がなされる領域だと思います。例えば次のような戦略があります。 データベースアクセス部分をモックにする 運用時のデータベースよりも高速なインメモリデータベースを使う(例えばH2 Database Engineなど) 開発者のローカル環境に運用環境と同等のテスト用データベースをインストールする 本記事では、Testcontainersを使ってデータベースアクセスを伴うテストを効率的に実施する方法をコードを交えながら紹介します。 本

                                                  Testcontainersを使ってテストを効率化しよう - 電通総研 テックブログ
                                                • X-RayはpytestとFlameGraphを組み合わせると便利 - Qiita

                                                  この記事を3行で AWS X-Rayをpytestで使うと便利 関数の通過や例外の発生をassertでテストできる X-Rayの可視化にFlameGraphを使えば、各関数の実行時間が分かりやすい この記事を書く理由 AWS X-Rayが便利なので、AWS環境へのデプロイの前でも使える使い方を紹介したい。 完成後の挙動 この記事で作成する単体テストを、Pytestで実行すると、 単体テストが吐き出したX-Rayのデータをもとに、下のようなグラフがローカルのPC上に作成されます。 FlameGraphと呼ばれているグラフです。炎のように下から上に伸びていくことが特徴です。 グラフの縦の方向は関数の呼び出しを表しています。 たとえばこのグラフなら、下から上に読んで、lambda_handler関数がnetwork_process関数を呼び出して、そこからgoogle.co.jpへのリクエストを

                                                    X-RayはpytestとFlameGraphを組み合わせると便利 - Qiita
                                                  • GitHub - guidepup/virtual-screen-reader: Virtual Screen Reader is a screen reader simulator for unit tests.

                                                    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                      GitHub - guidepup/virtual-screen-reader: Virtual Screen Reader is a screen reader simulator for unit tests.
                                                    • GitHub - kubeshop/tracetest: 🔭 Tracetest - Build integration and end-to-end tests in minutes, instead of days, using OpenTelemetry and trace-based testing.

                                                      Tracetest lets you build integration and end-to-end tests 98% faster with distributed traces. No plumbing, no mocks, no fakes. Test against real data. You can: Assert against both the response and trace data at every point of a request transaction. Assert on the timing of trace spans. Eg. A database span executes within 100ms. Wildcard assertions across common types of activities. Eg. All gRPC ret

                                                        GitHub - kubeshop/tracetest: 🔭 Tracetest - Build integration and end-to-end tests in minutes, instead of days, using OpenTelemetry and trace-based testing.
                                                      • 「swift-testingはじめました」 Quick/Nimbleからの置き換えの最初の一歩

                                                        potatotips#88での登壇資料になります。 WWDC2024で「swift-testing」に関するセッションが公開されていた経緯や、同僚が個人開発で利用していた事から関心を持ち、自分が携わるiOSプロジェクト内でも導入してみる前段の調査内容をまとめた資料になります。 自分もこれまで…

                                                          「swift-testingはじめました」 Quick/Nimbleからの置き換えの最初の一歩
                                                        • Rust vs. Go: Effective Unit Testing - Qiita

                                                          Retail AI Adventurers Advent Calendar 2023 の投稿です。 Retail AI は、トライアルカンパニー を軸とした小売におけるお客様の買い物体験の向上を目指す企業です。 この投稿では、本業(SRE)のかたわらで取り組む Backend Tech Stack について書きます。 題材は、「Rust 初心者として、Standard な Test Code の実装方法」についてです。 Rust における Test Code の書き方と Go で一般的な Table Driven Tests1 を使った Test Code について書きます。 tl;dr Rust でも Go と同じような Table Driven Tests1 を実装できます。 Rust では、compile 時に型チェックを行うため、Test Case の設計もより厳密になります。 R

                                                            Rust vs. Go: Effective Unit Testing - Qiita
                                                          • 【再放送】t-wadaさんが後世に残したい、実録レガシーコード改善 を見た感想

                                                            リンク connpass: 【再放送】t-wadaさんが後世に残したい、実録レガシーコード改善 - connpass t-wadaさんの資料 実録レガシーコード改善 / Working with Legacy Code: the True Record - Speaker Deck 会社で、「t-wadaさんのこの発表すごいよかったですよ」と聞いたので興味が湧いて再放送を見ることにしました。Findyさん、t-wadaさん再放送ありがとう… 特に個人的に面白かったポイントを書きます。 ソフトウェア開発の三本柱には優先度がある ソフトウェア開発の三本柱は、Version Control, Testing, Automationの3つです。今回t-wadaさんが取り組んだコードはどれも備えていませんでした。優先度順に手をつけたいけどどこから手をつけるべきか。 ここでVersion Contro

                                                              【再放送】t-wadaさんが後世に残したい、実録レガシーコード改善 を見た感想
                                                            • https://shiftasia.com/ja/column/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8Btdd%E3%81%A8bdd/

                                                              • https://www.uber.com/en-JP/blog/simplifying-developer-testing-through-slate/

                                                                • Ladle v3 | Ladle

                                                                  Ladle is a tool designed for building and testing React components through stories. It serves as a seamless alternative to Storybook and is built using Vite and SWC. Our main goal is to ensure it's as swift and user-friendly as conceivable. Introduced 18 months ago, Ladle is now utilized in 335 different Uber projects with a total of 15,896 stories. The community response has been positive as well

                                                                  • RustでTestcontainers入門: テストコードから依存サービスを起動してテスト環境を作成する - kymmt

                                                                    この記事はRust Advent Calendar 2023 シリーズ1の4日目の記事です。 あるソフトウェアをテストするとき、そのソフトウェアがデータベースやメッセージブローカのような外部のサービスに依存する場合に、その依存をどのように扱うかという問題がつきまとう。この問題へのよくある解決策としては 依存サービスを差し替えられるような設計にして、テスト実行時はモックに差し替える Docker Composeなどであらかじめ依存サービスをテスト用のコンテナとして立ち上げておき、テスト実行時はそれらのサービスが動くコンテナにアクセスする などが挙げられる。 今回はさらに別の方法として、テスト実行時にテストコードの中から依存サービスをコンテナとして立ち上げるためのフレームワークであるTestcontainersを紹介する。また、RustでTestcontainersを使うときの実例を紹介する。

                                                                      RustでTestcontainers入門: テストコードから依存サービスを起動してテスト環境を作成する - kymmt
                                                                    • テスト設計レビューで伝えた言葉まとめ

                                                                      broccoli @nihonbuson 「今回の観点に対するテストパターン、デシジョンテーブルで表現すると分かりづらいから、状態遷移図で表現してみましょうよ」 こんな発言がQAメンバーから出てくるテスト設計レビュー、いいぞー 2020-10-09 16:38:14 broccoli @nihonbuson 続き。 状態遷移図で描いてもらったので再度レビュー。 「状態遷移図を描くことで、どのように状態が変化していくのか整理できた」との感想。 よしよし。 ちなみに、状態遷移図をチャレンジしたメンバーは新卒1年目のテスト会社の人。 既に世の中の多くのテスト設計者よりも設計スキルが付いたかもね。 x.com/nihonbuson/sta… 2020-10-13 16:24:39 broccoli @nihonbuson ただ今回の題材は多少複雑で、描いてもらった状態遷移図が少し分かりづらかったの

                                                                        テスト設計レビューで伝えた言葉まとめ
                                                                      • Canon TDD

                                                                        What follows is NOT how you should do TDD. Take responsibility for the quality of your work however you choose, as long as you actually take responsibility. What follows is my response to “TDD suckz dude because <something that isn’t TDD>”, a frequent example being, “…because I hate writing all the tests before I write any code.” If you’re going to critique something, critique the actual thing. Wr

                                                                          Canon TDD
                                                                        • Test Talkで紹介されていた探索的テストの会をヘンリーでもやってみたら、早速、品質向上の効果が出た! - 株式会社ヘンリー エンジニアブログ

                                                                          LEADING QUALITYの輪読会後の雑談中様子 株式会社ヘンリーCEOの逆瀬川です。 4月から製品企画の責任者として開発ロードマップや要件開発を行っています。 特に今後、電子カルテを開発するチームでは人数も増え、これから大きな機能開発も増えていくため、これまで以上に品質向上への取り組みを強化しています。 具体的には、品質と信頼性を上げるための施策会議(品質と信頼性の会)や、不具合分析の定例会を開始しました。 本日は、品質と信頼性の会で出てきた施策のひとつである探索的テストを学び、早速実行したところ、大きな効果が出たので共有します。 弊社の品質の守護神 Aさん依存体質からの脱却!! 探索的テストに取り組むことになった背景としては、QAのAさんへの依存です。 元々医療事務出身のAさんがQAやテストを学び、チームの全てのテストを担っていました。ドメインエキスパートでもある彼女はスクリプトテ

                                                                            Test Talkで紹介されていた探索的テストの会をヘンリーでもやってみたら、早速、品質向上の効果が出た! - 株式会社ヘンリー エンジニアブログ
                                                                          • QAエンジニアから見る前職と現職での品質の差異 - Qiita

                                                                            役割について 第三者検証とQAの違いについては、お世話になっている先輩 @yamahiro2022 さんが昨年投稿された記事「第三者検証からQAに転職してみて」をぜひ読んでいただきたいです!(宣伝) ちなみに追加で私が個人的に感じている違いとしては以下です。 第三者検証 もちろん品質保証活動には最善を尽くすが、サービス提供者の立場として、責任の所在や組織としての印象なども若干意識して行動の範囲や方針を決めていた感覚 自社のプロダクト 責任は全部自社(つまり自分)に返ってくるので、役割や立場的な制限に縛られることなく自由に品質を追求できる感覚 今回の比較について 前提はこのくらいにし、この記事では主にドメインとユーザという2つの観点から、テストないしQA活動の差異をまとめていきたいと思います。 ドメインの違いによる差異 リテール 運用の想像がしやすい いち消費者として関わった経験があれば、顧

                                                                              QAエンジニアから見る前職と現職での品質の差異 - Qiita
                                                                            • バーチャルキャストの舞台裏 :メタバースの長期運用を実現する技術と戦略 | ドクセル

                                                                              バーチャルキャストの舞台裏: メタバースの長期運用を実現する技術と戦略 XR Kaigi 2023 株式会社バーチャルキャスト 打田 恭平 自己紹介 • 打田 恭平(HN:とりすーぷ) • 株式会社バーチャルキャスト • 相互体験開発セクション マネージャ • リアルタイムサーバ/Unityクライアント開発 • プロダクト全体のアーキテクチャ監修 • 個人活動 • 著書 : UniRx/UniTask完全理解 より高度なUnity C#プログラミング • Microsoft MVP 2018~

                                                                                バーチャルキャストの舞台裏 :メタバースの長期運用を実現する技術と戦略 | ドクセル
                                                                              • Developers Summit 2023 Summerでテスト自動化アーキテクチャについて発表してきました - カカクコムTechBlog

                                                                                システム本部デベロッパーエクスペリエンス室のQAエンジニア、伊藤由貴(@yoshikiito)です。 7/27に開催されたDevelopers Summit 2023 Summerにて、アーキテクチャで理解するテスト自動化システムという発表をしました。私の所属するシステム本部ではmablをテスト自動化に活用しています。今回はそのmabl社のおだしょーさんよりお誘いいただきまして、mablさんの枠で一緒にお話してきました。 タイムテーブル上では「満員」表示が出ており、けっこう注目していただけたのではと思っています! 発表の概要 デブサミ公式に掲載した文面がこちら。 システムテストの自動化を行うには、単純にツールを選ぶだけではなく、テスト自動化の仕組み自体をシステムとして捉え、設計することが必要です。 そのための材料として、テスト自動化アーキテクチャがあります。 本セッションでは、テスト自動化

                                                                                  Developers Summit 2023 Summerでテスト自動化アーキテクチャについて発表してきました - カカクコムTechBlog
                                                                                • Rails7 + ViewComponent + Hotwireでのコンポーネント指向なフロントエンド開発を試してみた

                                                                                  はじめに 本記事では環境構築について取り扱いません。 詳細につきましてはリポジトリを参照してください。 Railsのフロントエンド開発でつらいところ Railsでフロントエンド開発する場合に、よく使う部品はPartialなどで共通化しますよね? 小規模であればPartialだけで十分なのですが、コードベースが成長したり、複雑なユースケースを満たすようになると以下のような課題が生まれてきます。 1. データフローを把握しづらい PartialはControllerで定義したインスタンス変数を参照できるため、以下のようにデータフローが複雑になりがちです。 Partialに値を受け渡すときにlocalsでの受け渡しを必須にすれば解消できますが、曖昧な方針でPartialを実装しているとカオスになります。 2. JavaScriptとViewの依存関係が曖昧で保守しづらい View単位でJavaS

                                                                                    Rails7 + ViewComponent + Hotwireでのコンポーネント指向なフロントエンド開発を試してみた