ECSのCI/CD改善と標準化の取り組み / JAWS FESTA 2023 in Kyushu
https://jft2023.jaws-ug.jp/ の発表資料です
https://jft2023.jaws-ug.jp/ の発表資料です
ビジュアルリグレッションテストツール４選！ユーザーが語る各ツールのメリット https://trident-qa.connpass.com/event/308664/ X https://twitter.com/__sakito__
サバンナ便り〜自動テストに関する連載で得られた知見のまとめ（2023年5月版）〜 / Automated Test Knowledge from Savanna 202305 edition
2023/05/17(水) Qiita Conference 2023
はじめに テストコード一般の考え方 壊れにくいテストを書く 実装した通りに動作することではなく、仕様通りに動作することをテストする テストコードはシンプルにわかりやすく書く 失敗の原因がわかりやすくなるように意識する RSpecの書き方 テストケース名をitの引数で明記する letよりもlet!を使う 通常の変数と同じ方針に基づいてlet!を利用する subjectを使わない 不要なcontextでのネストを避ける matcherを適切に使い分ける factoryのデフォルト値に依存しないテストを書く 参考にしたブログ記事等 付録：RuboCop設定 We are hiring! サムネイル画像 はじめに テストコードを書く習慣も、近年ではかなり一般的なものになってきました。 ドワンゴ教育事業のバックエンドチームでも自発的にテストコードを書く文化は根付いており、実際に計測はしていませんが、
TDD実践を経て変わったこと
Qiita × Uzabase Tech Meetup#1 技術講演②「TDD実践を経て変わったこと」 で発表した内容になります。 https://connpass.com/event/210103/
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。まずは、ウォーターフォールモデルとアジャイルにおける品質担保の変化について話します。 セッションの概要説明 高橋寿一氏（以下、高橋）：高橋です。今日は講演というよりは、できればディスカッションみたいな感じにしたいと思っています。「アジャイル開発での品質視点の変化」というところを1時間弱お話しします。 ステレオタイプですが、ウォーターフォールからアジャイルへいったと。みんなハッピーなんですよね。書店に行くと、どんな本を読んでも「アジャイルが素晴らしい、ウォーターフォールじゃない」みたいな。やはりものを作る上でも、もののフレキシブルな使い方という
AI機械学習を用いた経営問題の解決や幅広い業種へ多数のコンサルティングの経験を持つ。AIプロジェクトに関するコンサルティングだけではなく、AI人材の育成、会社全体のDX化など幅広い分野で活躍中。AIに関わる講演を多数行なっている。 今回は機械学習でよく使うPythonのプログラムコードをアルゴリズム別に紹介していきます。 そして、機械学習といえばScikit-Learn。Scikit-Learnでよく使うコードを紹介します。 最後におまけとして、PandasやNumpyでよく使うプログラムコードも紹介します。 これらのプログラムコードはコピペで利用できるのでブックマークしておくことをおすすめします！ これからエンジニアを目指して機械学習のPythonを学びたい方、エンジニア入門としてプログラムコードを書きたい方はこの記事を参考にしてください。
「テストを書こうとしたけど、どう（いつ）書いたらいいかわからない」初心者向けガイドライン！ - HIKKYフロントエンドガイドラインより
本稿では、自動テストについての「ちょうど一歩くらい」進んだ内容について、述べていきます。 「テストを実施したいけど、どう書けばいいかわからない」という全人類は、これを読んでください。 損はさせませんよ！ これを読めば、「一歩目の知識」「初めてのテスト作成」「テストの初歩概念」を得ることができ、「次になにをすればよいか」がわかるようになります！！ 対象読者: 実際にテストを実装してみようと思ったけど、とっかかりがつかめなかった テストの概要はわかった（単体テストと結合テストガイドラインを読んだ） テストのTipsに興味がある なお本稿は株式会社HIKKYフロントエンドチーム向けのガイドラインであるものの、内容については筆者に一任されており、株式会社HIKKY及びその意向等とは無関係です。 テストってどういうフローで開発していくの？ どのタイミングでテストコードを書くの？ おおまかには以下の、
CTOの藤村です。つい最近まで STORES ブランドアプリ のチームでRailsを書いていました。 STORES ブランドアプリ のRailsリポジトリではdatabase_cleanerを（strategy = truncationで）使ってテスト中のデータベースをリセットしており、このことがテストコードの品質、速度などで重荷となっていました。 これを、テスト実行時にテストコード自体を書き換えて改善する仕組みを作り、先日無事Transactional Testへの移行が完了しました。ということで気分がとてもよいので、どうやったか共有させてください。 課題 STORES ブランドアプリのRailsのテストコードは速度に課題がありました。 テストデータを片付ける仕組みとして、 Railsエンジニアにはお馴染みのdatabase_cleanerというGemを使っていました。database_
なぜテストが開発を駆動するのか
はじめに TDD は Test-Driven Development を省略したもので日本語では『テスト駆動開発』という語が訳として与えられている。 TDD は現在多くの人に認知されていて、多くの実践者がいると思う。 私も TDD というスタイルが好きでよくそのような開発をする。 これまで、開発者の方と TDD について話すと『どうやる』の方に興味がいって『なぜ』の部分が置き去りになっていると感じることがあった。 例えば、『どうやればいいかわからない』といわれたのだが、TDDの典型的なお作法自体は知っているようなのだ。これはそもそも『なぜ』TDDをやりたいのかがわからないのではないのかと思った。 TDD はその名の通りテストでソフトウェア開発を駆動させるための開発スタイルだ。 なので、TDDをより効果的に行うためには、ソフトウェア開発がどのように行われるかを理解し、『なぜ』テストが開発を駆
はじめに 自分は2021年に新卒でweb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではReact×TypeScriptを利用したフロント周りの開発をメインで行なっていなす。 今回は実務でNext.jsプロジェクトにテストを導入することになり「React-Testing-Library」と「Jest」について改めて学び直したのでその内容を紹介します。 はじめに「React-Testing-Library」と「Jest」の概要を説明しその上で具体的なテストコードを何パターンか書いていきます。 この記事の対象者 フロントエンドのテストの概要を知りたい人 React-Testing-LibraryとJestについて知りたい人 具体的なテストの書き方を学びたい人 なお本記事では、React-Testing-Libraryの具体的な書き方についてをメインにしている
さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介 伊藤淳一氏：リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。
Playwrightを使ったE2Eテストを導入した話 - インフラ編 Playwright × Allure Report × AWS - Uzabase for Engineers
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日は Playwright を使ったE2Eテストの導入について、紹介させていただきました。 今回は作成したテストをAWS 基盤上で動かす方法を紹介させていただきます。 前回の記事 tech.uzabase.com E2Eテスト実行のタイミング NewsPicksでは 下記のタイミングで E2Eテストを実行させています。 ①リリース時のカナリーデプロイ後 NewsPicks ではカナリーリリースを採用していてカナリーへのデプロイが完了した後、カナリーに向けてE2Eテストが動きます。 ②開発環境デプロイ後 動作確認をしたい場合に feature ブランチなどでデプロイ後 E2Eテストを実行できるようにしています。 本記事では主に 「②開発環境デプロイ後」 を例に紹介します。 実行方法 具
XUnit Test Patterns に筆者の経験則を落とし込んでまとめています。 2024/01/25 TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜 の登壇資料です。 https://findy.connpass.com/event/306451/
**テスト駆動開発(TDD)で基礎を身につけましょう。**GoはTDDを学習するのに適した言語です。なぜなら、学習するのが簡単な言語であり、テストが組み込まれているからです。
この記事は、弁護士ドットコム Advent Calendar 2019 - Qiitaの2日目の記事です。 TL;DR TDDの実践方法を実際にコードを書いて解説します TDDの「レッド・グリーン・リファクタリング」のリズムを学ぼう 何度もテストを実行して、プログラムに対する不安を取り除こう TDDはテスト技法ではなく設計手法 TDD Boot Camp Sendai 9thに参加しました。TDDの伝道師和田さん（@t_wada）を講師に迎え、有志たちで開かれた勉強会でした。 午前中は和田さんによるTDDに関する講演とライブコーディング。午後は参加者同士のペアプロで出題されたお題を実装していく活気あるイベントでした。 イベントを通じてTDDはテストファーストのことだと考えていた自分は目を見開かされました。TDDは単にテストファーストでプログラムを実装することではなく、実装（ソフトウェア）が
Karateとは Karateは主にe2eテストを自動化するツール。cucumber的なfeatureファイルを書くとそれを実行できる。WebAPIのテストがその中心的ターゲット github.com graalvmのjsライブラリで実現しているっぽいので、featureファイルからJavaも呼べる。 個人的にBDDというのが結構いいと思っていて、ビジネスルールの仕様なんかをビジネスサイドと意識合わせする場合に使えると思っている。アンクルボブはFitnesseというツールを作っている。 FrontPage Fitnesseは名著『実践アジャイルテスト』でも紹介されていたもの 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践) 作者:Janet Gregory,Lisa Crispin発売日: 2009/
Go製のネットワーククライアントに対する継続的 / Fuzzing for network client in Go
Go Conference 2021 Spring
TL;DR フロントエンドのテストが壊れやすく要因の一つは、ユーザがどのようにソフトウェアを使うかをクエリに反映できていないからかも testing-library はソフトウェアを使うユーザの気持ちを反映させやすいようにクエリの優先度をつけていて、それに従うほうがいい 優先度の低いクエリも役に立つことがある 運用しているアクセシビリティなどの実装のガイドラインに沿うようなテストを作るとき アクセシビリティの低い実装をリファクタリングするためのテストを作るとき はじめに フロントエンドのテストに用いるツールとして testing-library が知られています。testing-library は提供しているクエリに優先度をつけています。この優先度は、どういう基準でつけられているのでしょうか。 この記事では、 testing-library のガイドを読みながら、クエリの優先度を「ユーザの
Vue.js アプリでユニットテストを書くには、Vue Test Utils や Jest など、知っておくべきことがそれなりにあります。 現在、Vue CLI でアプリを作っていますが、ユニットテストを書くために色々と調べないといけませんでした。 今回はその過程で理解した Vue.js でのユニットテストの基本を以下にまとめます。 Vue.js のユニットテスト まず、Vue.js では何を「ユニットテスト」として考えるのかを整理します。 ユニットテストの単位 Vue.js アプリは、複数のコンポーネントで構成され、それぞれのコンポーネントが連動しながら動きます。 そのため、ユニットテストの単位は「コンポーネント」となり、コンポーネントごとにテストを書いていきます。 何をテストすべきか？ コンポーネントごとにユニットテストを書くということですが、コンポーネントのどの部分に対してテストを書
テストコード内では条件分岐を書かないようにする
テストコード内では条件分岐を書かないようにする 2023.01.21 誰でも読める愚直なコードであることの 1 つの目安として、テストコードの中に if 文や三項演算子などの条件分岐が入り込んでいていないことが上げられます。if 文が存在するコードはアンチパターンであるといえます。実際に if 文がテストコードの中に入り込んだ例を見てみましょう。 テストコードは誰でも読める愚直なコードであることが求められます。テストコードにはある種のドキュメントのような、コードの仕様を説明する役割が求められているためです。テストの期待結果が変数になっていて、定義元までジャンプしないと値を確認できないだとか、条件分岐やループが入り込んでいて複雑性が上がっている状態ですと、素直に読みやすいとは言えません。 コードの中では重複排除をするためにさまざまなテクニックを駆使することがありますが、これは単にテストコード
執行役員 VP of Engineering 兼技術部長の @hsbt です。9月に発売する LOST JUDGEMENT に備えて龍が如くシリーズの過去作品を一通りプレイし終えたので、次はモンハンストーリーズ2か何をプレイしようかなあと迷っている日々です。 GMO ペパボ(以下、ペパボ)では 2021 年の技術方針として「ふつうの開発をできるようになる」というスローガンを掲げています。 「ふつうの〜」という私が以前に所属していた永和システムマネジメントでよく使われていた形容詞です。すごいエンジニアがすごいテクノロジーを使ってすごいプロダクトを作って世界を変える、そういうやり方を夢見るのではなく、開発者一人一人が毎日の「ふつうの開発」のやり方のレベルを少しずつ高めていくことですごいプロダクトを作っていこう、という意味がこのスローガンにはこめられています。 ふつうの開発をできるようになる で
こんにちは。BacklogのGit機能の開発を行っているテリーです。 今回はGitチーム（後述する僕の所属するチーム）でAutifyによるリグレッションテストの自動化を進めてみて感じたメリットと工夫したところ、苦戦したところを紹介したいと思います。 スモールチームの規模感とテストの現状 BacklogのGitチーム 長らくBacklogは固定のチームが専任で固定の機能をみるような体制になく、アプリケーションエンジニアが比較的流動的にBacklog全体の機能を担当しており、なんとなく“この人”は“この機能”が得意というような体制でした。 ですが最近のチーム編成により固定のチームが固定の機能を開発するようなフィーチャーチームがいくつかできました。Gitチームはその中で生まれたBacklogのGitの機能についての開発責任を持つチームです。チームメンバーは3人で、そのメンバーでインフラからフロン
Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った
Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。
「アプリケーションが壊れているのに検知できないテストコード」を書かないようにするための、べからず集 - Qiita
はじめに テストコードを書くことは重要です。 テストコードがないアプリケーションよりもテストコードがあるアプリケーションの方が望ましいことは間違いありません。 ですが、テストコードも書き方を間違えると、アプリケーションが壊れているのに正しく検知できないテストを書いてしまう可能性があります。 この記事ではそんな「アプリケーションが壊れているのに正しく検知できないテスト」のコード例を「〜するべからず（〜してはいけない）」の形式で紹介し、その修正方法を説明していきます。 サンプルコードはRSpecで書いてます（でも他の言語でも考え方は同じはず） サンプルコードはRailsアプリケーションをRSpecでテストする場合を想定したものになっていますが、基本的な考え方自体は他の言語やテスティングフレームワークでも適用可能なはずです。 RSpecのイロハについて先に学んでおきたいかたは「使えるRSpec入
追記(2019/11/2) 今回の記事で深く扱えなかったリファクタリングに関する記事を書きました。 「汚いコード、綺麗なコードって何？」リファクタリングを考えてみる テスト駆動開発とは テスト駆動開発とは、「テスト => 実装 => リファクタリング」という流れを何回も何回も繰り返してプロダクトを成長させていく開発手法です。 もう少し詳しく説明します。次の３段階を繰り返します。 1. テストケースを考えるフェーズ これは設計を考えることに等しいフェーズです。このオブジェクトがどんな機能を持っていて欲しいか、どういう風に使われるか、そしてその時にどんな結果を返して欲しいか、という思いをテストケースに込めます。 重要なのはこの時に実装のことは一切考えず、どう使われるかを考えることです。 2. 実装するフェーズ テストをパスするためだけの最低限度の実装をします。この時も抽象化やキレイなコードなど
はじめに こんにちは、インフラエンジニアの 高山 です。 この記事は Enigmo Advent Calendar 2021 の 9 日目の記事です。 現在、BUYMAをオンプレからAWSへ移行するプロジェクトを進めています。 テスト環境の移行は完了し、本番環境の移行をしようというところです。 本番環境の移行をする前に 性能的に問題ないことを確認するため、本番環境と同程度のスペックで検証環境を構築し負荷テストを実施しました。 まだ終わっていませんが、今の時点で得た知見を記事にしようと思います。 負荷テストツール選定 詳細は割愛しますが、 以下のような要件からAWSの分散負荷テストのソリューション(正式名称はDistributed Load Testing on AWS 以下、AWS負荷テストソリューションと呼ぶ)を使うこととしました。 大規模な負荷テストができること 複雑なテストシナリオが
Kaigi on Rails ( https://kaigionrails.org )の登壇資料です。
はじめに テストでコード品質を担保していくことは、継続的インテグレーションの観点などで必要不可欠です。そして、十分なテストコードが書かれているかどうかの指標として、よく使われるものといえばテストカバレッジがあります。 Goではgo testコマンドと、go tool coverコマンドがカバレッジ計測の機能を担っています。今回は、これらのツールをより深く使い込んでいくために、既存機能の一歩進んだ使い方や最新機能について紹介します。 なお、本記事で紹介しているコマンドなどはmacOSで実行した場合の例となります。 オリジナルのカバレッジ統計データを集計する まずは既存のカバレッジの統計データを取得する方法を振り返り、より詳細な情報を集計するアプローチについて紹介します。 Goのカバレッジツールで出力できる統計データ 既存のgo testコマンドおよびgo tool coverコマンドで出力で
Agile Studio プロデューサーの木下です。アジャイル開発をはじめるには、基本的な語彙やプラクティスをチームにいる全員が知ることが大切です。また、アジャイル開発を実践していく上ではスクラムのみ...
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版） 」をテーマに登壇。まずは、セッションテーマと学習用テストについて話します。 本セッションのレギュレーション 和田卓人氏：よろしくお願いします。みなさん、こんばんは。和田卓人です。今日は「サバンナ便り」というタイトルで、自動テストに関する知見についてお話ししたいと思います。 まず今日のレギュレーションといいますか。どんどん話していくんですが、オンラインの講演はライブ感とかリアルタイム感とか、そういったところがとても大事になってきます。 なので、みなさんもTwitterで「Qi
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: History of RSpec – Steven R. Baker 原文公開日: 2021/05/09 著者: Steven R. Baker 日本語タイトルは内容に即したものにしました。 私がTDD（テスト駆動開発）をチームで教え始めたのは2001年のことでした。当時のTDDはまだかなり新しい概念でしたので、テストを自動化したチームもほとんどなく、XP（エクストリームプログラミング）やTDDについて聞いたことがある人も皆無でした。テストを最初に書くことで設計を進めるという概念は当時まったく知られていなかったので、TDDを理解するのに皆とても苦労していました（20年経った今でも、この事実が完全に変わったとは言えません）。 思い返せば、あの当時は厳しい状況でした。最善を尽くしてTDDの概念を説明し、どうにかしてチームの関心を惹こう
CircleCI上のRSpecによるテスト実行時間を25min -> 12minに短縮する技術 - ANDPAD Tech Blog
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
LINE LIVEを支える負荷テストの知見。ベンチマーク環境により信頼性の高いシステムを実現する方法
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog サービス・機能やそれにまつわる開発の裏話や取り組みを聞く「ProductStory」シリーズ。2015年にスタートしたライブ配信サービスのLINE LIVE。いつでもどこでも、無料でライブ配信＆視聴が可能という便利さから、サービス開始以来多くのユーザーにご利用いただいてきました。昨今ではコロナ禍の影響からオンライン上で楽しめるエンタメの重要性が高まっており、LINE LIVEのニーズはさらに増しています。 サービスの信頼性を高めるため、LINE LIVE開発チームは、サービスに対する負荷テストを実施するために構築されたベンチマーク環境を用いています。定期的な負荷テストを行うことでパフォーマンス上の課題を洗い出し、システムのさら
マイクロサービスの開発とテストファースト／テスト駆動開発 【Mercari Gears Lecture Series】 | メルカリエンジニアリング
こんにちは、Mercari Gears事務局です！ この記事では、動画公開以来とても反響のある Mercari Gears Lecture Series #47〜#49「マイクロサービスの開発とテストファースト／テスト駆動開発」の動画の内容を記事に起こしたものです。 今回の実際の動画はこちらになります、興味があればぜひご覧ください！ MERCARI GEARS Lecture Seriesとは？ MERCARI GEARS Lecture Seriesは、株式会社メルカリをはじめとするメルカリグループ各社が、これから目指す方向や、これから取り組む技術的なチャレンジについてご紹介するエンジニア向けのレクチャー動画シリーズです。 MERCARI GEARS Lecture Series お話する人の自己紹介 株式会社メルペイ 柴田芳樹 九州工業大学 情報工学修士 1984年 富士ゼロックス 入
リファクタリングに関する何か - 日々常々
リファクタリングの話をするとき、焦点が合ってないなーと感じることがたまにあるのでざっくり描いてみた。 自分のために描いたものなので、なんか違うなーって思ったらご自身で描いてみるといいと思います。レッツモデリング。 破線は依存、実線は変換。長方形は名前などで明確に識別可能なもの、角丸は様々なものを包含する活動。雲は思いです。 描いた時の経緯と言うか 該当ツイート: リファクタリングって常時やるものなんですよね。もちろん「よーしやるぞー」って感じで行うものもあるんですけど、それは深呼吸的な。 とは言え。やったことがない、やってはいけない文化（動いているコードに触ってはいけない）に染められてしまっている、そのような方に「無意識にやれ！」と言っても、何の意味もないので言いません。むしろ害悪ですらある。 該当ツイート: 無意識にやるようになって、ようやく「リファクタリング」がカタログ化される前の「偉
ContentsBasic project setupThe basic setup consists of four steps: Create the project and source directoriesCreate a package.jsonGet a .gitignore, tsconfig.json, .eslintrc.jsInstall TypeScript & dependenciesNote: This guide uses yarn, but if you prefer npm it has similar commands. # Create project folder mkdir my-project cd my-project # Create source folder and files mkdir src touch src/main.ts sr
フロントエンドの開発時に仮の API を使いたいってシチュエーションはわりとあると思います。 そんな時に、Mock Service Worker を使うと便利だったのでまとめます。 Mock Service Worker とは？ Mock Service Worker は、ネットワークレベルで API リクエストをインターセプトして mock のデータを返すためのライブラリです。API リクエストを含む処理のテストや、開発時の mock サーバーの代替として利用出来ます。 テストでの利用については以前こちらの記事でまとめました。 今回は開発時のモック API としての利用について書きます。 開発用の API というと、JSON Serverが有名ですが、Mock Service Worker では Service Worker を使ってリクエストを返すため、別プロセスでローカルサーバーを立
Introducing Rome
We’re excited to announce the first beta release and general availability of the Rome linter for JavaScript and TypeScript. This is the beginning of an entire suite of tools. Rome is not only linter, but also a compiler, bundler, test runner, and more, for JavaScript, TypeScript, HTML, JSON, Markdown, and CSS. We aim to unify the entire frontend development toolchain. Rome is a monolithic tool con
Rails 7.0 + Ruby 3.1でゼロからアプリを作ってみたときにハマったところあれこれ - Qiita
Ruby on Rails Advent Calendar 2021の枠が空いていたので、あとから登録しました はじめに 個人的なプロジェクトになりますが、僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」を2022年前半にRails 7.0バージョンにアップデートしようと考えています。 そこでこの本の中で使っているサンプルアプリケーションをRails 7.0でゼロから作り直してみました。フロントエンド周りを中心に結構考え方が変わっている部分があったので、「ここでハマった！」とか「こういうポイントを押さえておくといいかも」という点をあれこれ書いてみます。 なお、Rails 7.0版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Storybookの実力をフル活用するChromatic
N予備校開発でのRSpecの書き方指針 - ドワンゴ教育サービス開発者ブログ
「旧来のテスト担当者の仕事は、たぶんどんどん減っていく」 アジャイルへの移行に必要な品質向上の定義
機械学習によく使うPythonのコード一覧まとめ | AI入門ブログ
RSpecのテストコードを実行時に書き換えて実行速度を改善した話 - STORES Product Blog
【入門】フロントエンドのテスト手法まとめ - Qiita
過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方
テストコードを負債化させない上手な付き合い方 / Test Code Management
テスト駆動開発でGO言語を学びましょう | テスト駆動開発でGO言語を学びましょう
テスト駆動開発（TDD）とは何か。コードで実践方法を解説します - パンダのプログラミングブログ
APIテスト自動化ツールKarateをBDDツールとして使う - まっつんの日記
testing-library でユーザの気持ちになって書くフロントエンドのテスト
Vue.js ユニットテストの基本まとめ - Qiita
ふつうの開発と TDD ワークショップ - Pepabo Tech Portal
スモールチームにおけるAutifyを用いた効率的なE2Eテストの自動化 | 株式会社ヌーラボ(Nulab inc.)
僕たちがテスト駆動開発をする理由 - Qiita
AWS移行のため、大規模で複雑な負荷テストをやった話 - エニグモ開発者ブログ
FactoryBot the Right Way
Goのカバレッジツールを使いこなす | gihyo.jp
アジャイルプラクティスマップを公開しました | Agile Studio
和田卓人氏が教える、自動テストの使い方 学びを自動テストとして書く「学習用テスト」という考え方
RSpecの作者が振り返る歴史（翻訳）｜TechRacho by BPS株式会社
Starting a TypeScript Project in 2021
Mock Service Worker で開発用のモックAPIを作る
noodlenodu.hatenablog.com
www.bengo4.com
www.ferrari.com
note.com/shi3zblog
anond.hatelabo.jp
aoi0.px.ebb.jp