Jest + enzymeで行うReactのユニットテスト（単体テスト）について
その他にReactにenzymeを連携させるためのenzyme-adapter-react-16や、Jestのスナップショットを行うためのreact-test-renderer、Jestでenzyme-matchersを使用するためのjest-enzymeなどが状況により必要となります。 なお、create-react-appを使う場合は、デフォルトでJestが組み込まれており、特にBabelなどの設定を行う必要はありません。enzymeについては、別途インストールが必要です。 JestについてJestはテスティングフレームワークです。以下のような特徴があります。 JestはJasmine 2をベースに作られていて、JasmineのMatcherがそのまま使えます。Facebook製でReactのイメージが強いですが、他のフレームワークなどでも普通に使えます。Node.js上のjsdomで
GoでHTTP Clientのテストを書く
GoでHTTP Clientのテストを書いてみます。 テストしたい項目 正常なRequest & Response 無効なAuth Tokenを投げたとき Responseが5xxのとき Response Bodyが予期しない形式のとき タイムアウトしたとき ポイント http.Clientは差し替えられる実装にする http.Client.Transportを差し替えることで、実際にHTTP Requestをすることなく、任意の*http.Responseが返ってくる状況を作ることができる http.Client.Transportってなんぞ？という方はこちらを参照 Go http.RoundTripper 実装ガイド#http.RoundTripper とは 実装 APIクライアントの構造体 http.Clientはデフォルトでhttp.DefaultClientを使い、オプションによ
Go でコードカバレッジを取得する - Qiita
func Greet(name string, lang string) string { switch lang { case "en": return fmt.Sprintf("Hello, %s.", name) case "ja": return fmt.Sprintf("こんにちは, %s.", name) } return "..." } type TestCase struct { Name string Language string } func TestGreet(t *testing.T) { cases := []struct { in TestCase expected string }{ {TestCase{Name: "World", Language: "en"}, "Hello, World."}, {TestCase{Name: "Kazumasa",
その設計、変更に強いですか?単体テストできますか?...そしてクリーンアーキテクチャ - Qiita
はじめに アーキテクチャや設計の書籍や記事、これまでの経験も踏まえ、学んだ事をここにまとめたい。(まだ、勉強中なので微妙なところもあるかもしれません。お気付きの点があればご指摘いただけるとありがたいです。) 参考文献や参考記事は、本当に良書、良記事で非常に参考にさせていただきました。 生意気なタイトルにしてしまいましたが、自分への戒めということもあってこのタイトルにさせていただいたので、ご容赦ください。 ある共通した話題 設計やアーキテクチャについて書かれた書籍や記事を読んでいく中で、言葉は違えどかなりの高確率で共通するテーマが存在した。 そう、それが 「変更に強くなろう」 といった趣旨のテーマだ。 アーキテクチャや設計に関する書籍や記事は様々な方法論で、これを実現しようとしていた。 今回のテーマと記事の構成 今回は、「変更に強くなろう」というテーマの中で重要だと感じた概念や考え方をまとめ
結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
bashでのif/while条件判断 に使える[[ / (( 条件の一覧＜コマンド・ファイルの存在などで条件分岐＞ - それマグで！
bash ではいろいろな条件で分岐が出来る。 ifで使えるいろいろな条件を見てみたいと思う。 数値判断系 数字を比較するときは以下を覚えておけばいい。 (( 1 > 0 )) (( 1 >= 0 )) (( 1 < 0 )) (( 1 <= 0 )) (( 1 == 0 )) (( 1 != 0 )) (( 0 )) # 終了ステータス 1 /if では false (( 1 )) # 終了ステータス0 /if ではtrue (( ! 0 )) # 終了ステータス 0 /if では true (( 1 && 1 )) (( 0 ||1 )) 数値を比較するときは if (( 1!=0 )) ; then echo yes ; fi と書きます。この数値判断系の出来ることはlet と全く同じです。 (( ))のdouble parensis での記述方法は また別記事もっと詳細に書きます。
Vim script版 power-assert! テスト書いてないとかお前それ Vim script の前でも同じこと言えんの? - haya14busa
Vim script で最高の assertion 体験，vital-power-assert を作りました haya14busa/vital-power-assert テスト書いてないとかお前それ Vim script の前でも同じこと言えんの? ということで Vim script 版 power-assert, vital-power-assert を作りました. Vim script でも power-assert できてテストをバリバリ書けるんだから Vim で書いてる他の言語でテスト書いてないとか Vim が泣いちゃいますね…(煽り，そしてブーメラン) 使い方とか 力こそパワー!! 百聞よりパワー!! 使っている様子です 1 2 3 4 " in your vimrc NeoBundle 'vim-jp/vital.vim' NeoBundle 'haya14busa/vital
golangでvetコマンドやtestコマンドを実行したときにvendorディレクトリを除外する方法 - エンジニアはこわくない
下記の記事で書いたように、golangでディレクトリ(プロジェクト)をまるごとvetやtestしていると、たまに困ったことが起きるようになりました。 tsujitaku50.hatenablog.com それは 「ディレクトリ(プロジェクト)をまるごとvetやtestしていると、vendorディレクトリも一緒にvetやtestする」 ということです。 つまりvendorディレクトリ配下にエラーが起きるようなコードが含まれている場合、それも同時に検出されてしまうということです。 これはめんどくさい。 できればvendorディレクトリだけ除外したいですよね。 ということで、調べました！ vendorディレクトリを除外して、プロジェクト(ディレクトリ)まるごとvetやtestするコマンドは 下記になります！ go vet $(go list ./... | grep -v /vendor/) 少
第2回 テストエンジニアが知っておくべき《画面編》のポイント | gihyo.jp
はじめに 前回の記事を読まれた皆さんは、「発注者ビューガイドライン」（画面編）をダウンロードされましたか？ 今回の記事は画面編が手元に置いてあることを前提にして進めますので、まだの方は、すぐにでもダウンロードしてください。 ダウンロードされた方はお読みになりましたか？ PDFのページ数にして291ページ（表紙含む）のドキュメントです。PCで300ページ近くある文書を読むのは大変ですし、かと言って印刷するのも大変です。結局面倒になって読まなかったかもしれません。 その気持ち、よくわかります。そこで、本記事ではテストエンジニアが知っていても良いと思われるコツをいくつかピックアップして紹介します。馴染みのあるコツがいくつかあれば、いつか膨大なドキュメントも制覇できるでしょう。 本記事の構成 「発注者ビューガイドライン」（画面編）は、大きく「表現編」と「レビュー編」に分けることができます。「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - k1LoW/awspec: RSpec tests for your AWS resources.
GitHub - stretchr/testify: A toolkit with common assertions and mocks that plays nicely with the standard library