テストでは何をテストすべきか – recompile.net
ソフトウェア開発でのテストとは何かを単純に言うと、成果物が期待通りであるかを検証する作業といえる。こう動作してほしいという期待を入力に、成果物がその通りに動作するかを検証するのがテストである。 となると、成果物とは何で、期待とは何かが問題になるのだけれど、これが一筋縄ではない。というのも、システムは十分に複雑なので、ある部分を複数の部分に分けることもできるし、その部分をより大きな部分のパーツにすぎないとみなすこともできるからだ。 だからといって、一番大きな単位でもって期待通りにあるかどうかを検証すれば済む話かというとそういうわけでもない。というのも、大きな単位には大きな単位なりの期待が、小さな単位には小さな単位なりの期待というものが存在するからだ。 システム開発は、ひとつのものさしではかることができない。システムをつかって業務を遂行できるかという検証と、その部品であるクラスの検証では、成果
Test Doubleを使うとテストの信頼性/保守性が下がるのか？ - Fly me to the Luna
最近はユニットテストを行うテストコードにおいて、Test Doubleを多用してます。Test DoubleとはMockとStubを合わせた総称です。Test Doubleを用いると、信頼性や保守性が下がると言われることがあります。しかし、それはTest Doubleの用法を誤っているためではないかと僕は思うのです。Test Doubleの用途はユニットテストのスコープをテスト対象のクラスに限定するために用いるべきものです。実感として、Test Doubleを使っているからと言って、ユニットテストの信頼性/保守性が下がったとはあまり感じていません。 良く誤解されていますが、Test Doubleはスローテスト問題を解決するための手段ではありません。Test Doubleをうまく利用すれば、結果的にスローテスト問題を解決できます。しかし、スローテスト問題を解決するための手段ではないのです。ス
シフトレフトがなぜ効果的なのか「抽象度」から考える
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 18日目の記事です。 はじめに ログラスの龍島(@hryushm)です。 ソフトウェア開発において、「シフトレフト」すなわち開発の早い段階でテスト計画を立て、実施していくことが全体的なコスト削減や価値提供の早期化につながるとよく言われています。 この記事では、シフトレフトによってもたらされる効果をログラスでの実例を用いて紹介した上で、なぜ効果が出るのか？を「抽象度」というキーワードから紐解いてみようと思います。 本記事ではスクラム開発においてPBIを完了させる中でシフトレフトしていくことを念頭に書いていきますが、ソフトウェア開発の任意のタイミングにおいて適用できる概念だと考えています。 テスト設計を実装前にやることの有用性 まずシフトレフトによって何が起こるのか？を考えます。PBIに書かれた受け入
自動テストの信頼性を高めるミューテーションテストの活用に向けて
2024/10/18 iOS Test Night #13の登壇資料
KubernetesとGaugeを活用したTDD開発事例
XP祭り2018の発表資料です。 発表した時の資料より文字を多くしてます。
Property based testing を試してみよう - Qiita
Property based testingとは 歴史的な背景として2000年にJohn HughesとKoen Clasessenによって 開発されたQuickCheckがProperty based testingとしてHaskellエコシステムに実装されました。 QuickCheckはプロパティ（特定の入力が与えられると出力として期待される特性） を与えることで、 テストデータをランダムに生成して、失敗するケースを見つけるHaskellで実装されたフレームワークです。 それによってテスト対象のシステムがプロパティに従っているかどうかをチェックします。 QuickCheckは単体テストだけではなく、統合テストやサンプルベースのテスト等幅広く使われています。 このテスト方法はProperty based testingとして知られるようになりました。 2020年現在は、HaskellのQ
PO,SMに送るテスト自動化の8原則に5箇条を添えて / scrumniigata2023
Scrum Fest Niigata 2023
Spring+DDDでのアプリケーションアーキテクチャとテスト戦略 - Qiita
GxPのやすば（@nyasba） です。 本記事はグロースエクスパートナーズアドベントカレンダー 2日目の記事です 弊社が得意とする継続的な開発のためには保守性が高いアプリケーションにしていく必要があり、今自分が関わっている案件では**DDD（ドメイン駆動設計）**を採用しています。 今日はJava/SpringプロジェクトでDDDを実践する際のアプリケーションのアーキテクチャ（レイヤ構造やパッケージ構成など）とテスト戦略についてまとめてみます。 ※会社としても採用実績はありますが、あくまで個人の思想に基づく内容です。 はじめに Springで開発している案件といっても、レイヤ構成やパッケージの切り方やそれに伴うテスト戦略は様々です。弊社内でも特に標準が定められているわけではありませんので、案件によって切り方が違うのが現状です。 パッケージの切り方自体はコードを見れば理解できるものですが、
テストの正常系、異常系、準正常系について - Qiita
テストの正常系、異常系、準正常系について ソフトウェアテストは正常系、異常系、そして準正常系のケースをカバーすることが重要です。これにより、アプリケーションが予想どおりに動作し、エラーや問題に対処できるかどうかを確認できます。 1. 正常系テスト 正常系テストは、アプリケーションが正常な状態で正しく動作するかどうかを確認します。ユーザーが期待通りの操作を行う場合の挙動をテストします。例えば、ユーザーがログインし、メールを送信するなどです。 2. 異常系テスト 異常系テストは、アプリケーションが異常な状況に遭遇したときにどのように振る舞うかを確認します。ユーザーが誤った情報を提供したり、システムエラーが発生した場合のテストです。これにより、エラーメッセージが正しく表示され、セキュリティの問題やデータ損失を防ぎます。 3. 準正常系テスト 準正常系テストは、正常系と異常系の中間に位置します。一
単体テストを簡単にするためのDI - Qiita
##はじめに まだエンジニアに成りたての頃、3年ほど継続で改修している案件で単体テストを書いたことがあります。 創業から継ぎ足し続けているタレのような案件（?）だったため、かなりつらみのある単体テストになり一時期はテスト嫌いになりました。 昔の私に限らず、テストに対して嫌なイメージを持っている方は多いような気がします。 しかし、何年かエンジニアをやっていて、実際には単体テストが悪いのではなく、Testableでないコードが悪いのだと思うようになりました。 ##単体テストの何がつらいって？ それはモックアップとかテストデータの用意とかです。それですよ。 JMockitとか使ってモックを用意する。単純なメソッドなら簡単でもstaticとかprivateとかmember変数とか...そういった面倒なモックに心を削られるんです。 あとは、工夫を凝らしたテストデータをDBに流し込んで...、まだ完成
xUnit Test Patternsから学ぶ12個のユニットテストの原則 - Qiita
本エントリは、xUnit Test Patterns: Refactoring Test Codeという書籍の「Chapter5 Principles of Test Automation」の内容をベースに、12個のユニットテスト原則についてまとめていきます。この書籍は、2007年に販売されたものですが、今でも十分役に立つユニットテストに関する原則を伝えています。 ウェブでは、次のURLでも内容を見ることができます。 自動ユニットテストの原則 ここで紹介されるものは、ユニットテストで確認したい quality のリストです。ですので、直接適用する「パターン」ではありません。 「何をやるか」よりも「なぜやるのか」という観点においてまとめられています。 本エントリでは、xUnit Test Patterns: Refactoring Test Codeで紹介されている12個の原則をベースに、ほ
UnitTestを書く上で注意すべきこと - Qiita
※ 時折こぼけを挟んでおります。 UnitTestを書く上で注意すべきこと 誰に向けた記事か プログラミングは基本的に行える(2~3年程の経験) まだアーキテクチャについては良く分かってない つまり私 モチベーション クリーンアーキテクチャ 238p から引用 テスト容易性のための設計 システムと強く結合したテストは、システムに合わせて変化する必要がある。システムコンポーネントに対する小さな変更であっても、結合した多くのシステムが壊れたり、変更が必要になったりする。中略。共通のシステムコンポーネントを変更すると、何百や何千というテストが壊れる可能性がある。これは、脆弱なテストの問題（Fragile Tests Problem）と呼ばれている。 脆弱なテストは、システムを硬直化させるという悪影響を及ぼす。システムを少し変更しただけで大量のテストが失敗するとなると、開発者は変更するのをためらう
Go でやる mutation testing ~テストの品質を評価しよう~ - Qiita
Mutation testing とは テストの品質を評価する手法の一つ テスト対象のプログラムの一部を機械的に書き換えたときに、テストが失敗させられるかを確認する手法 大まかな流れは以下の通りです。 プログラムを一部改変 改変されたプログラムのことを "mutant" と呼びます 1.で改変した状態でテストを実施 テストが失敗するかどうかをチェック いずれかのテストが失敗するなら、 テストが十分であるとし、OKとします 全てのテストが成功するなら、テストが不十分であるとし、NGとします このプロセスをたくさん実行し、いろいろなプログラムの改変("mutant")を試してその結果のOKの割合が高いほうが質の高いテストであると判断します。1 テストが失敗する場合に、mutation testingとしてはOKとなります。ややこしいので、この記事では以下のように表現することとします。 テストが
テスト自動化の8原則について - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 個人で細々と書いていたブログ記事をQiitaに移行しております。 もしかしたら、既に読んだことがある人がいるかも知れないですね ここに書くのはあくまでも私自身の解釈であり、所属する組織などとは一切関係ございません。 *むしろ違っていたりしたら教えてほしいです。 詳しくは、テスト自動化研究会の記載されているページでご確認ください。 テスト自動化の8原則 - テスト自動化研究会 テスト自動化の8原則 1. 手動テストはなくならない 自動化が優れていても、人間でしか出来ないテストはもちろんある。 例えば、ユーザビリティテスト。 自動テストで不
BDDとユニットテストの流派 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. BDDとは BDD（ビヘイビアー駆動開発） はTDDを拡張した手法です。 1つのシナリオを書き、そのシナリオを満たすように実装を進めていきます。つまり、ユニットテストの範囲は単一クラスではなく、複数の依存関係にあるクラスも含みます。 基本的にビジネスマン（非エンジニア）から見たとしても理解ができるテストであり、受け入れテストとも言われます。 詳細に言うと、受け入れテスト（ATDD）はユーザー寄りで、振る舞い駆動開発（BDD）は開発者寄りと見る人もいます。 どちらかというとUIテストに使われる傾向があり、「Given-When-Th
半自動テスト状態にならないためのコツ - Qiita
この記事はAutify Advent Calendar 2021の22日目の記事です。 自己紹介 株式会社レコチョクでQAを担当している清崎（きよさき）と申します。 社内では独立したQAチームが組織横断として存在しており、自社サービス、toB向け、toC向けと展開しているサービスに対して、ビジネスチーム/開発チームとQAチームが協力しながらテストを実施しております。 株式会社レコチョクの紹介 当社は2001年に国内の主要レコード会社の共同出資で設立され、おかげさまで2021年で20周年を迎えました。 2002年に着うた(R)のサービスを開始し、現在はPC、Android/iOS、ゲーム機などの多様なデバイス向けにダウンロード配信やストリーミング配信を展開しております。 他にもtoB向けの事業に対しても積極的に行っており、タワーレコード社との協業提供にて定額音楽配信サービス「TOWER RE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
privateメソッドのテストって書かない方がいいんだっけ？
APIテスト自動化の勘所
テスト駆動開発入門
[golang] 言語仕様から見るunittestとClean Architectue - Qiita![[golang] 言語仕様から見るunittestとClean Architectue - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3c8b5cc76e85e5312bbcbd37e6bff0df063042b0/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCZ29sYW5nJTVEJTIwJUU4JUE4JTgwJUU4JUFBJTlFJUU0JUJCJTk1JUU2JUE3JTk4JUUzJTgxJThCJUUzJTgyJTg5JUU4JUE2JThCJUUzJTgyJThCdW5pdHRlc3QlRTMlODElQThDbGVhbiUyMEFyY2hpdGVjdHVlJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1jMjFkOTAxZDA2MTY2NGFkMTA3NmEwNjUyMzNlZGRmMA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBraXNoaWJhc2hpMyZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MzdjYzgxNTUxNWZkZTQ5MjNhZjJhMGE4OTRjMzU5Njg%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g44Km44Or44K344K544OG44Og44K65qCq5byP5Lya56S-%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D89c33daafde906beea4a338e5d823039)
