PHP Conference Japan 2024の登壇資料です。

はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう!』 『今までモック使ってたけど意外とモック使わなくても書けるね!』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 もくじ テスト駆動不具合修正 or リファクタリング手順 なぜテストが書けないのか 依存関係を排除できればテストは書ける 依存関係を排除するためのカギになる考え方 書けない単体テストがなくなる2
broccoli @nihonbuson 「今回の観点に対するテストパターン、デシジョンテーブルで表現すると分かりづらいから、状態遷移図で表現してみましょうよ」 こんな発言がQAメンバーから出てくるテスト設計レビュー、いいぞー 2020-10-09 16:38:14 broccoli @nihonbuson 続き。 状態遷移図で描いてもらったので再度レビュー。 「状態遷移図を描くことで、どのように状態が変化していくのか整理できた」との感想。 よしよし。 ちなみに、状態遷移図をチャレンジしたメンバーは新卒1年目のテスト会社の人。 既に世の中の多くのテスト設計者よりも設計スキルが付いたかもね。 x.com/nihonbuson/sta… 2020-10-13 16:24:39 broccoli @nihonbuson ただ今回の題材は多少複雑で、描いてもらった状態遷移図が少し分かりづらかったの
PlaywrightによるE2Eテスト入門 / Introduction to E2E Testing with Playwright
お久しぶりです。セガの阪上です。前回の記事「QAエンジニアってどんな仕事?~ゲーム開発におけるテストの世界~」を寄稿してから6年が経ちました。今回は、前回の記事以降に発表した講演内容を振り返りつつ、前回紹介したQAエンジニアという職種から、クオリティエンジニアに役割を再定義した経緯について紹介します。 また、今年のCEDEC2024の講演『「龍が如く」も「スーパーモンキーボール」も自動化!クオリティエンジニアリングチームによるマルチゲームエンジン対応で進化した「龍が如くスタジオ」のテスト自動化環境について』は楽しんでいただけたでしょうか? マルチゲームエンジン対応となったテスト自動化環境について、説明しきれなかった内容も補足しますので、最後まで楽しんで読んでいただけたら幸いです。 目次 目次 「QAエンジニア」から「クオリティエンジニア」になった経緯 (2018年~)開発・QAにおける自動
スクラムフェス新潟2024の発表資料です。
Introduction This guide should help you to make sure you are following our best practices and writing tests that are more resilient. Testing philosophy Test user-visible behavior Automated tests should verify that the application code works for the end users, and avoid relying on implementation details such as things which users will not typically use, see, or even know about such as the name o
$ cd $HOME $ wget https://github.com/pmd/pmd/releases/download/pmd_releases%2F7.8.0/pmd-dist-7.8.0-bin.zip $ unzip pmd-dist-7.8.0-bin.zip $ alias pmd="$HOME/pmd-bin-7.8.0/bin/pmd" $ pmd check -d /usr/src -R rulesets/java/quickstart.xml -f text $ cd $HOME $ curl -OL https://github.com/pmd/pmd/releases/download/pmd_releases%2F7.8.0/pmd-dist-7.8.0-bin.zip $ unzip pmd-dist-7.8.0-bin.zip $ alias pmd="$
2024/04/17: 更新 内容を更新した記事を書きましたので、よかったらこちらも併せて、ご覧ください。 zenn.dev こんにちは!フロントエンドエキスパートチームの@nus3_です。 kintone のフロントエンド刷新プロジェクト(フロリア)では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足: React v18 では @testing-library/react の renderHook を使う 参考
Unlike previous versions of JUnit, JUnit 5 is composed of several different modules from three different sub-projects. The JUnit Platform serves as a foundation for launching testing frameworks on the JVM. It also defines the TestEngine API for developing a testing framework that runs on the platform. Furthermore, the platform provides a Console Launcher to launch the platform from the command lin
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめに こんにちは。福岡工業大学3年の嵩原ひびきです!QAエンジニアインターン生としてLINE Fukuoka株式会社に2ヶ月間お世話になり、ノンコーディングツールを活用したテスト自動化について勉強させていただきました。この記事では、期間中に学んだ内容について紹介していきたいと思います。 QA Engineering室(以下QAE室)について 私は今回、QAE室という組織にお世話になりました。QAE室ではインターン受け入れの前例がなく、今回が初めてとのことでした。(受け入れありがとうございます!) QAE室は2020年にLINE Fukuoka内に設立された組織で、テストのみならず、要件定義・設計/開発なども含めた開発プロセ
はじめに MNTSQ(モンテスキュー)株式会社 フロントエンド担当の安積です。 入社して4ヶ月とちょっと。 コードに取り組もうと入社して、まさに日々格闘しております。 私の後ろの席にはこんなバズ記事書く人や、こんなイカつい記事書く人が座ってまして、そんなプレッシャー期待の中からお送りいたします。 tech.mntsq.co.jp tech.mntsq.co.jp 昨日はこんな記事も公開されています。 tech.mntsq.co.jp はじめに 現在のステータス またはMNTSQ考古学 リファクタリングやるぜっっ! 仕様書大事だよね 差分指向テストとは テスト環境の概要 テストデータ ブラウザ操作自動化 スクリーンショット比較 Playwriteの操作 ちょっとコードのサンプル 最後に この記事を書いた人 現在のステータス またはMNTSQ考古学 コードベースから見たMNTSQのフロントエン
JaSST Tokyo 2018の招待講演で話した資料(こちら)に書いてあることですが、今までの人生で私自身は、デジタル複合機コントローラソフトウェア開発を4回もアーキテクチャを変えて行いました。デジタル複合機の難しさは、ハードウェアからの非同期なさまざまなイベントとユーザからの様々なイベントを両方を上手く処理しなければならず、かなり複雑なソフトウェアとなります。 ソフトウェアエンジニアとして合計すると10年以上をデジタル複合機コントローラソフトウェアの開発に従事し、マルチスレッドプログラミングを行ったことになります。公開資料に詳細情報は含まれていませんが、資料にある「Take 3」と「Take 4」は、デジタル複合機コントローラソフトウェアを完全にテスト駆動開発で行うというものでした。 4回ともマルチスレッドプログラミング(厳密には、Take 4はマルチゴルーチン(goroutine)プ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く