Laravel 10 基礎から学ぶテスト入門
◆ 本書について 本書は、Laravel で PHPUnit を使ったテストを書く際の基礎知識やノウハウをまとめた本です。もちろん、ドキュメントも大事なリソースではありますが、ドキュメントだけでは良く分からない内容も多くあります。 まずは、本書でテストの基礎知識を身につけ、更にその上でドキュメントを見て、より多くの知識を身に付けていただければと思います。 ◆ 対象読者 ・Laravel のテストを初めて習われる方又は少しかじった事のある方 ・Laravel 自体については、そこそこ知識がある方 ◆ 本書を読み終えた頃には ・Laravel の実際の案件でテストを書けるようになる。 ・より品質の高いシステムを作成する事ができるようになる。 ・テストを書くのも楽しくなる（かも）。
ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
GitHub Copilotと快適なユニットテストコード作成生活
こちらで登壇させていただいた資料です。 https://trident-qa.connpass.com/event/314818/ ※ こちらは2024/05/23 時点の私の考えとなります。更新の予定はございませんのでご了承ください
より信頼できるクエリを書くために、SQLでもテストを書く - ハヤオキスルフクロウ
はじめに こんにちは、久しぶりに技術系の記事を書きます、株式会社カンムで機械学習エンジニアをしている fkubota です。 今日はSQLについてです。 弊社に入社してから毎日のようにSQLのクエリを書いてきました。 クエリを書き始めてからもう3年が経とうとしています。 日々クエリを書きながら少しずつ自分のスタイルが出来上がってきているのを日々実感しています。 僕は 正確で 読みやすく 再利用しやすいクエリを 高速に 生み出すための工夫を重ねてきました。 結果的にテスト駆動開発ぽいスタイルが生まれたので今日は紹介してみようと思います。 似たような記事がないので少しドキドキですが温かい気持ちで読んでもらえると嬉しいです。 対象読者 対象読者は、分析のためにクエリを書いている人とします。 プロダクトに乗せるクエリというより、ビジネス的になにか示唆を得たいときにクエリを書く人を想定します。 痛み
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
筋肉ですべてを解決する人のプログラミング上達方法｜牛尾 剛
私は米国の超大手クラウドベンダーの中の人をやっており、普段はアメリカに住んで気づいたことをブログに記録しているのだが、今回は趣を変えて、日本で出会った凄い人からの学びを書いてみようと思う。 プリンシパルを目指して前回の下記のブログで、マネージャにならずに、プリンシパルというレベルを目指し始めたので、少しづつ自分のふるまいを変えることにしているが、これはそれの一環だ。 人生最後の大きなチャレンジの戦略を考える｜牛尾 剛 (note.com) 筋肉の豊富なケンさん 私が日本に居たときの同僚で、ケンさんという人がいる。筋トレ仲間として、筋肉がものすごいので、凄いなと思っていたのだが、彼は筋肉だけではなくプログラミング力もえげつなかったことを覚えている。 あるハッカソンで普通の人なら１つか２つの機能を試すところを、彼は１０個ぐらい、それもものすごく高度に組み合わせてすごく短い時間に凄いアプリを作っ
テストケースの名前には条件と結果を含めた方が良い - 感情を込める
という考えにたどり着いたので、考えのスナップショットをとっておく。 Go言語における、テスト関数名とサブテストのname引数の値を「テストケースの名前」・「テスト名」と呼ぶことにしている。 (*testing.T).Run(name string, f func(t *testing.T)) bool テスト名に近いものとして、(*testing.T).Errorや(*testing.T).Logの引数がある。これらはテスト実行時の出力に含まれるが、テストケースを分かつものではない。あくまで、特定のテストケース内の情報を増やすものだ。対するテスト名は、（通常は）テストケースを分割できる最小単位である。 テストケースがテスト名の単位で存在するということは、テスト名はそのテストケースを十分に表現できていたほうがよいということだ。さもなくば、検証・変更しようとする仕様に対応するテストケースや、実
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは 『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』は、初版の発行部数は22,000部、2021年8月出版の改訂版は13,000部に上り、技術書としては異例のシリーズ累計35,000部を突破しました。（2023年6月現在） ソフトウェアテスト専門企業であるバルテス株式会社の技術者が執筆した、ソフトウェア開発工程のテストについて、基礎からしっかり体系的に学習できる本格入門書です。 このストーリーでは、初心者から上級者まで幅広い層に読まれている、ソフトウェアテストのバイブルともいえる本書完成までの経緯や苦労話、著者であるバルテスの石原 一宏氏と布施 昌弘氏が伝え続けたい想いをお伝えします。 テスト設計に必要な考え方を身につけられ
モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則 - 千里霧中
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
今度こそユニットテストを書き始めるために
はじめに Unit Testが大事、ということ自体はあまり異論はないと思うのですが、最初からTDDがしっかりできてるような現場ならいざ知らず、そうではない場合は中々うまく入れれない事も多くあります。なのでこうすると導入しやすい、という観点で以下の動画でそのあたりのことを話したのですが、補足も含めて記事でもまとめておきたいと思います。 これはユニットテストですか？ ユニットテストとは？ ユニットテストとは何でしょうか？ 一応、テストの資格試験を実施しているISTQBの定義では以下のように定義されます。 component testing (unit testing) A test level that focuses on individual hardware or software components. Synonyms: module testing, unit testing この
Golangのテストはテーブルドリブンテストで！ - Qiita
package main // Square ２つのintを受け取りそれらを掛け合わせた物を返す関数 func Square(a, b int) int { return a * b } package main import ( "testing" "github.com/stretchr/testify/assert" ) func TestSquere(t *testing.T) { asserts := assert.New(t) for _, td := range []struct { title string input []int output int }{ { title: "2×3の答えが6になる", input: []int{2, 3}, output: 6, }, { title: "3×5の答えが15になる", input: []int{3, 5}, output
freeeの自動テストの全体構成 - freee Developers Hub
こんにちは、Software Engineer in Qualityチーム(通称SEQチーム)の @teyamagu です。 私たちのチームは普段自動/手動テストの基盤開発や開発フィードバックサイクルの高速化に向けた開発をおこなっています。 その一環で、先日、社内でfreeeの自動テストシステム全体像を共有したのですが、この辺りのことを社外の友人達と話したところ、自動テストの具体的な構成や普段の運用など事例が少なく、どんなことをやっているのかイメージしにくいとの話を伺ったので、社内向け原稿をちょっと手直しして、おすそ分けと言うことで、ここで紹介します。 特に変わったことをおこなっているわけではありませんが、自動テストの関係性の理解に参考になれば幸いです。 基本的な考え方 自動テストが既存のデプロイ・リリースのブロッカーではなく、開発のフィードバックを加速させるために、自動テストそのものが高
「テストコードにはテストの意図を込めよう」の発表報告＆補足説明＆質問回答 #vstat - ブロッコリーのブログ
先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。 veriserve-event.connpass.com 今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。 目次 目次 発表内容 発表に対する補足 【補足1】都道府県のテストについて 【補足2】Parameterized Testsへの利用について いただいた質問の回答 【質問1】リーダブルなテストコードの勉強方法はありますか？ 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？ 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか? 【質問4】
リーダブルテストコード / #vstat
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 https://vimeo.com/742517199/e001ac43ac ＜参考リンク＞ Twitter https://twitter.com/jnchito Blog https://blog.jnito.com/ Qiita https://qiita.com/jnchito プロを目指す人のためのRuby入門［改訂2版］ https://gihyo.jp/book/2021/978-4-297-12437-3 Everyday Rails - RSpecによるRailsテスト入門 https://
エンジニアとして今の自分を形成した本を5冊紹介する - パンダのプログラミングブログ
エンジニアとして今の自分を形成した本5冊 エンジニアとして働くにあたって自分が大きく影響を受けた本を考えてみた。もちろん他にもあるが、今回は以下の5冊に絞って紹介する。 Clean Coder（クリーンコーダー） Team Geek Clean Architecture（クリーンアーキテクチャ） テスト駆動開発 LeanとDevOpsの科学 この記事の対象者としては、独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人を主に想定している（かつての自分がそうだった）。 特にチーム開発、オブジェクト指向言語でのコーディング、テストコードを書いた経験がある人が読んで、本に書いてあることを実践すると自分の成長を実感するだろう。 「Clean Coder」、「
jestでDBありのテストを高速化する
課題link お手伝いしているシステムでNestJSを採用しているバックエンドのテストが遅いという課題があったので対処した。 前提link フレームワークDBテストランナーその他 テストの総数は700弱。 最終結果link 最終的には2段階の改修を経てローカルのテストが3倍速程度高速化した。 # before Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 total Snapshots: 0 total Time: 925.063 s Ran all test suites. Done in 926.48s. # ts-jestを@swc/jestに置き換えた Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
privateメソッドのテストって書かない方がいいんだっけ？
https://x.com/t_wada/status/1747078614351495284?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://twitter.com/nyker_goto/status/1651194333050343424?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developers
