効果的なunittest - または、callFUTの秘密
Contents unittest を効果的に使うための覚書 目的 ルール: テスト対象のモジュール(module-under-test)をテストモジュールに直接importしない ガイドライン: モジュールスコープでの依存を最小限にする ルール: 各テストメソッドでは、１つの事実だけを確認する ルール： テストメソッドは内容を表すようにしよう ガイドライン: setupはヘルパーメソッドで提供しよう。テストケースのselfで共有するのはやめよう。 ガイドライン: フィクスチャは可能な限り簡潔に ガイドライン： フックやレジストリなどの利用は注意深く ガイドライン: 依存関係を明確にするためにモックを利用する ルール: テストモジュール間でテキストを共有しない まとめ https://twitter.com/tokibito/status/412074246026698753 ということで
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
レガシーコード改善勉強会 開催レポート
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27（土）の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード（テストコードが無いコード）と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 ＜開催趣旨・目的＞ テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
デシジョンテーブルの解説 - ソフトウェアテストの勉強室
デシジョンテーブルとは デシジョンテーブルとは、決定表(JIS X 0125)[1]として規格が定義されています。論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールの組合せます。プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。 図1. デシジョンテーブルの例（駐車場料金の割引計算） デシジョンテーブルを作成する手順は一般的に以下の通りです。 分析対象・テスト対象の持つ条件・原因を洗い出し、それぞれを行として追加します 処理・動作・結果を洗い出し、それぞれ行として追加します 起こりうる条件・原因の組合せを作成し、それぞれ列として追加します 作成した列のうち、集約可能な列の組を圧縮します 組合せの作成と圧縮についての検算をします デシジョンテーブルを使うことで以下のようなメリットが挙げら
xUTP Magazine - xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」
書いた人：@yujiorama(id:yujiorama) 目次 目的 はじめに テストの匂い テストコードの匂い Obscure Test Conditional Test Logic Hard-to-Test Code Test Code Duplication Test Logic in Production 振る舞いの匂い Assertion Roulette Erratic Test Fragile Test Frequent Debugging Manual Intervention Slow Tests プロジェクトの匂い Buggy Tests Developers Not Writing Tests High Test Maintenance Cost Production Bugs さいごに 目的 この連載記事の目的は次のような感じです。 xUTP読書会で得られた知見を
単体テストを中心としたテストレベルの話
鈴木三紀夫 @mkoszk @kyon_mm TEFへの返信の前にツイートで。要求工学の基礎では要求のスコープというのが定義されています。ビジネス要求、システム要求、ソフトウェア要求がそれに当たります。これを僕は社内研修でずっと「要求のレベル」と読んでいたんです。テストレベルとの対比で言っていたんですね。 2012-01-03 02:31:09 鈴木三紀夫 @mkoszk @kyon_mm 対比すると、受け入れテスト、システムテスト、単体／統合テストになるからです。でもね。それは要求のレベルじゃなくて、要求のスコープだと指摘されて、最初は何を言っているのか分からなかったんだな。だけど時間が経つにつれて分かる部分が増えてきたんだ。 2012-01-03 02:33:33
単体テスト/結合テストなんて存在しない
テストプロセスを再定義する時代が来た。 単体テスト、結合テスト、システムテストといったテストレベルがテスト設計において寄与しているメリットはあるのか？ また、それらが結局はプロジェクトのマイルストーンをひくための単なる慣習的な単語であり、実作業に悪影響を与えているのではないか。 という疑問をもったうさみみことkyon_mmの話にソフトウェアテストクラスタの方がつきあってくださいました。 kyon_mmは現在、ソフトウェアテストを勉強しはじめたばかりの人です。 続きを読む
6.2. IEEE 829 - テストを実施するさいのドキュメント・テンプレート | 第三者検証サービス(テスティング・サービス)［東芝情報システム］
IEEE 829 ( IEEE Std. 829-2008, IEEE Standard for Software and System Test Documentation ) は、ソフトウェアのテストを実施したさいに作成するドキュメントの種類、および、各ドキュメントに記述する項目についての標準 ( Standard ) です。 IEEE が作成しています。IEEE 829 は、テストのプロセスに沿ってドキュメントを定義しています。 IEEE 829 は、テストを実施するさいのドキュメント・テンプレートとして利用することができます。弊社が 第三者検証サービス (テスティング・サービス) で使用する 「東芝情報システム 第三者検証技術標準」 の 「テスト作成文書」 は、この IEEE 829 を基に、弊社のテスト実務経験に基づきカスタマイズしたドキュメント・テンプレートです。 IEEE 8
UnitTestPatterns - igaiga fswiki
最終更新時間：2008年04月26日 14時11分54秒 This Page is translated from follow URL. http://www.marcclifton.com/tabid/87/Default.aspx (c) 2005 Marc Clifton All Rights Reserved. This page is translated by Kuniaki IGARASHI, Yasuhiro SUGINO. mail : igarashikuniaki@gmail.com このページは上記のwebページを日本語訳したものです。 翻訳のおかしい部分、こなれていない部分はご指摘頂ければありがたいです。 現在鋭意翻訳中です。 Introduction ユニットテストは常に人々に強い反応を引き起こすようです。ユニットテストを導入する際には満場一致で、良いユニット
テンプレートから学ぶ 受注する開発者のためのテスト仕様書
1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。 お客様（発注者）はプロジェクトを起案する際、何を作るかを「
リファクタリングのための回帰テストの書き方 - 千里霧中
リファクタリングで定番のテスト活用方法として、変更前と変更後で挙動が変わってないことをテストコードで検証する、というものがある。違う用例で使われることもあるが、ここではそのテストを回帰テストと定義する。 そうしたリファクタリングでの回帰テストとしては、大きく以下の2パターンが挙げられる。 新しいコードの出力と古いコードの出力を比較するテストを書く。 満たすべき仕様を検証するテストを書く。そして古いコードと新しいコード両方がそれをパスすることを確認する。 今回は前者のテストをどう作っていくか、について扱っていきたいと思う。 簡単な場合 新しいコードの出力と、古いコードの出力を比較するテストというのは、満たすべき仕様を検証するテストよりも、一般的に実装が容易であることが多い。というのも、そのアプローチでは、テスト対象の仕様をよく考えなくとも、カバレッジなどを基準に網羅性を高めることで必要なテス
『テストパターン』
JUnitとエクストリームプログラミング（XP）の普及によって、テストファーストやテスト駆動開発（TDD）が身近になった。Kent Beckが説くみたいにテストから書き始める、なんて極端なことをする必要はないと思うが、開発中のソフトウェアにそれなりの品質を保証しようとするなら、ソースコードにテストスイートくらいは付いてくることが期待されるようになっている。 とはいえ、実際にJUnitでテストを書いてみると、思ったより難しい。難しいので、あまりテストを書かなくなる。 なぜ難しいのかというと、テストコードというのはその性質上、「宣言的」だからだ。テストは、「何々という条件を入力したときに、何々という結果が発生しなければならない」というような、プログラムが満たすべき事前条件と事後条件をチェックする。分かりやすく言うと、「What」の記述だ。 一方で、たいていのプログラマが普段書いているプログラム
【連載】実践ソフトウェアテスト考現学 | エンタープライズ | マイコミジャーナル
Copyright (C) Mainichi Communications Inc. All rights reserved. 掲載記事の無断転載を禁じます
Webの負荷テストに使えるフリーソフトウェア | OSDN Magazine
Webアプリケーションおよびサーバの高負荷時の挙動を確認する方法の1つが、擬似的に負荷をかけてテストを行うことだ。ここでは、そうしたテストを実施するフリーソフトウェアをいくつか試し、それぞれがどんなタイプのサイトに適しているかを調べた。 負荷テスト用のツールはいろいろあるが、メンテナンスが行われていないもの、フリーでないもの、インストール手順が明確でないものを除くと、curl-loader、httperf、Siege、Tsung、Apache JMeterの5つが候補として残る。 JMeterについては、すでにDaniel Rubio氏が取り上げているので、ここでは詳しく説明しない。ただし、最後のまとめでほかのツールと共に簡単に触れている。 curl-loader curl-loaderは、「SpirentのAvalancheやIXIAのIxLoadの代替として使える強力かつ柔軟なオープン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pytest へようこそ！
Web開発におけるテスト関連ドキュメントの作成・運用術
InfoQ: より良いユニットテストためのガイドライン
- ワークショップ
あなたのテスト、単なる動作確認になっていませんか？