Reactのユニットテスト2021
React でユニットテストをするときのベストプラクティスはいつも悩むのですが、とりあえず 2021 年 2 月時点では、こうかなーというのをまとめてみます。 まずテストランナーは jest で確定です。ここで悩む要素はまずありません。 では、React のテストをどうやるか？です。 公式の react-dom/test-utils を使う 公式の react-test-renderer を使う @testing-library/react を使う 選択肢としてはこの三種類が有名なところでしょう。 公式という響きはとても魅力的ですが、実は公式ドキュメントから「ボイラープレートを減らすため、エンドユーザが使うのと同じ形でコンポーネントを使ってテストが記述できるように設計されている、React Testing Library の利用をお勧めします。」という形で、@testing-library
例えば, Singleton を避ける | Born Too Late
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
レガシーコード改善ガイド・知識編 - Strategic Choice
書籍「レガシーコード改善ガイド（Working Effectively with Legacy Code）」の「第1部 変更のメカニズム」より、レガシーコード改善作業の前提となる知識をまとめます。目次レガシーコードとは変更：ソフトウエア一般 ソフトウェア変更の課題ソフトウェア変更のリスクソフトウェア変更の方法回帰テストによるソフトウェアの保護回帰テストの問題点単体テストによるソフトウェアの保護単体テストの境界線変更：レガシーコード特有 レガシーコード変更の課題レガシーコード変更の心構えレガシーコード変更の方法関連エントリレガシーコード改善ガイド・知識編（本エントリ）レガシーコード改善ガイド・戦術編レガシーコード改善ガイド・戦略編出典レガシーコード改善ガイド (Object Oriented SELECTION)作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉
テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
【速報】JUnit5 はこうなる!?【プロトタイプ】 | DevelopersIO
渡辺です。 DevelopersIOでの100本目のエントリーがJUnitネタとなりました。 自分がJUnit実践入門を執筆したのは2011年から2012年にかけてです（出版が2012年11月）。 それからJava8がリリースされていますが、JUnit4自体は大きな進化はしていませんでした。 昨日、JUnit Lambda Prototypeが公開されました。 まだプロトタイプということで、今後の変更は大きいかと思いますが、いよいよ次世代のJUnitの足音が聞こえてきた感じがします。 今回は、このドキュメントからJUnit Lambdaの概要と方針について速報をお送りしたいと思います。 なお、現在JUnitチームでは、このプロトタイプに対するフィードバックを募集しています。 ここはこうじゃないとかはてブコメントする前にTwitterやGitHubでフィードバックを！ JUnit Lambd
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
TDDの効果の研究をまとめた研究 - やっとむでぽん
TDDに関連する論文をいろいろ探し回っていたのですが、今年(2013年)に書かれた、既存のTDD研究をまとめて全体像を描こうとしている研究を見つけ、しかも無料で公開されているので、紹介したいと思います。 以下のように書いてあるので、学会(?)発表用のものであって、雑誌に載ったわけではないのかな(アカデミックな話はよくわからない。査読があるかどうかが重要なんだっけ)。 This is the author's version of the work. The definite version was published in Proceedings of the 6th International Conference Software Quality Days (SWQD 2014), Vienna, Austria, January 14-16, 2014 "Effects of Tes
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
関ジャバでJUnitな話をしたので #kanjava #junitbook - 日々常々
関西Javaエンジニアの会'13 7月度 - connpass 関西Javaエンジニアの会'13 7月度を7月31日に開催しました。6月に続いて二ヶ月連続ですね。三ヶ月連続は無いので心配しないでくだ……あ、8月にはJavaEEと言うかGlassFishと言うか、あれがありますね！（「関ジャバのイベント」ではありませんが。） Java EE 7 & GlassFish について語ろう - DevLOVE関西 | Doorkeeper 今回の関ジャバは@jyukutyoさんのindy、@chipstar_lightさんのDDD、2連続となる@haljikさんのパズラー、あと私のコレでした。 スライド スライドあげておきます。内容の詳細は……結局このブログへのリンクになるので、中で触れてるのもあわせてリンク並べておくことで代替。 JUnitの知識を棚卸し #JJUG - 日々常々 assertT
JUnit実践入門の読みどころ #junitbook - やさしいデスマーチ
先日のエントリーではたくさんのブクマありがとうございます。Amazonでの予約も好調とのことで、うれしい限りです。 JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) 作者: 渡辺修司出版社/メーカー: 技術評論社発売日: 2012/11/21メディア: 単行本（ソフトカバー）購入: 14人 クリック: 273回この商品を含むブログ (69件) を見るというわけで、書影も出てきました！ 思えば、JUnitのセカイというエントリーで、たくさんの「わっふる」をいただき、出版の決意を固めたわけですが、気がつくと書き始めて1年経ってました。ようやく、情報を公開できる段階まで来たわけです。 今回のエントリーでは、JUnit実践入門の発売に先立ち、本書の構成と各章の概要をお伝えします。予約を迷っている方は、本エントリーを読んだ上でご検討いただければ幸いです。
JUnit API探訪：@Before/@After, @BeforeClass/@AfterClass アノテーション - Diary of absj31
JUnit API探訪：アノテーション一覧 - Shinya’s Daily Report @Before アノテーション / @After アノテーション Before (JUnit API) After (JUnit API) JUnit4をやってみよう @BeforeClass,@Before,@AfterClass,@Afterそれぞれの違いを検証する。 JUnit(JUnit4)の概要〜利用方法【ユニットテスト - テスト】 ＠みっちーわーるど JUnit4 - TRANCE ARTS 技術情報Wiki メソッドの前後に、都度実行する。 @BeforeClass アノテーション / @AfterClass アノテーション BeforeClass (JUnit API) AfterClass (JUnit API) JUnit4をやってみよう @BeforeClass,@Befor
TDDと相性の良いC、C++のユニットテスティングフレームワークとは - 千里霧中
これまでTDDで使えるC、C++向けのユニットテスティングフレームワークをいくつか紹介してきました。その一連の紹介の総括として、今回は、C、C++でのTDDを対象とした場合、どのようなテスティングフレームワークが望ましいのかについてまとめたいと思います。 TDD向けのテスティングフレームワークに求められる条件 TDD向けのテスティングフレームワークに求められる条件については、以前Advent Calender向けの「TDDのはじめかた #TddAdventJp - 千里霧中」の冒頭で触れさせて頂いています。少し加筆して下記に転載します。 軽快にテストを実行できる。TDDにとって、実行に1秒以上かかるテストはもう遅すぎます。そのような実害ある遅さの直接的原因になるフレームワークは避けた方が無難です。 簡潔なテストコードでテストを実装・実行できる。Assertion MethodやTest M
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
Continuous Tests
Monitors, builds and tests your code Contribute or SHUT IT! ContinuousTests is an open source continuous test runner for the .NET platform. The project relies heavily on user contributions and it lives by the "contribute or shut it!" creed. As a result of this we have stopped putting up binaries and expect the user to compile it from source. We also have plans of developing tests to assess the aut
xUTP Magazine 0002号
『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。 巻頭言 xUnitester Hotlinks: 第一回 和田卓人さん xUTP Topics: 第二回 xUnit Test Patterns の世界観「テストコードの不吉な匂い」 mockitoでサクサクTest Double生活(下) TDDでのテストの構築と保守 その１ ユニットテストで支えるTDDの作業 TDD Boot Camp レポート 編集後記 次号予告 次号は2012年1月末頃を予定しています。 掲載予定記事 おねがい 記事へのご意見、ご感想や、「こんな記事が読みたい」、「あの人の記事が読みたい」、といったご希望などがありましたら、お気軽にお問い合わせください。 記事の投稿も随
TDD Boot Camp 札幌 2.0
The document describes a Test Driven Development (TDD) Boot Camp event that was held in multiple iterations from 2011 to present. It provides details on the schedule and topics covered during the multi-day training workshops, which introduce participants to TDD techniques using Java and Ruby programming languages. The goal of the boot camp is to help developers learn how to use TDD as part of thei
自動化テストで気をつけること - give IT a try
先日、会社のメンバーからテストの自動化に苦労しているという話を聞きました。 そういえば、一言で「テストの自動化」といっても結構奥が深いので、自動化テスト初心者が注意すべき点や重要なポイントをちょっと考えてみました。 自動化テストの注意点 どのような処理でもプログラムとして自動化できるプログラミングスキルを実装者が持っていること。 結局、手作業でやっていることのほとんどをプログラムとして実装する必要があるからです。 いつでも、どこでも、誰が実行しても同じテスト結果が返ってくるようにテストを作成すること。 たとえば、テストの成功・失敗がシステム日時や外部ファイルやデータベース等に格納された不安定なデータに依存しているとテストがすぐに壊れます。 壊れたテストを放置しないこと。 少なくともソース管理システムにコミットしたファイルはすべてパスするようにしましょう。 壊れたテストを放置すると、誰も自動
Windows アプリケーションでは NUnit を使える構造設計を | Moonmile Solutions Blog
ちょっとメモ的に書き下し CppUnit やら NUnit やらは、10年前から使っているのですが、これらの単体テストをうまく活用するためにはコツが入ります。と、言うか、うまく活用できるようなプログラミングスタイル、構造設計、進捗管理状態、になっていないとうまく活用できません。 これ、経験上ですが、NUnit を導入するときの技術的な問題(NUnitを知っているとか知らないとか、Assert.AreEqual だとかなんとか)よりも障壁が大きかったりします。 いくつか導入時のときに注意するポイントを上げると、 ■構造設計が無理なパターン まず、xUnit 自体、UI を必要としない設計にしないとうまく動きません。例えば、Windows アプリケーションでのボタンクリックのエミュレート、Web サイトでのリストボックスの選択、なんていうのが内部ロジックとべったりくっ付いていると、それだけでう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JUnit4をやってみよう
