テストコードは仕様書。 https://t.co/yifJ1LLBdc

はじめに みなさん、DRY原則はご存知でしょうか? DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記:タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
Using matchers ScalaTest provides a domain specific language (DSL) for expressing assertions in tests using the word should. Just mix in should.Matchers, like this: import org.scalatest.flatspec._ import org.scalatest.matchers.should._ class ExampleSpec extends AnyFlatSpec with Matchers { ... You can alternatively import the members of the trait, a technique particularly useful when you want to tr
TotT 104 GTAC 61 James Whittaker 42 Misko Hevery 32 Code Health 31 Anthony Vallone 27 Patrick Copeland 23 Jobs 18 Andrew Trenk 13 C++ 11 Patrik Höglund 8 JavaScript 7 Allen Hutchison 6 George Pirocanac 6 Zhanyong Wan 6 Harry Robinson 5 Java 5 Julian Harty 5 Adam Bender 4 Alberto Savoia 4 Ben Yu 4 Erik Kuefler 4 Philip Zembrod 4 Shyam Seshadri 4 Chrome 3 Dillon Bly 3 John Thomas 3 Lesley Katzen 3 M
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
When the unit tests are passing but the application is broken https://t.co/vxBZQPgiru
私の趣味は数学の証明のリファクタリングである。教科書に書かれた数学の証明は、まずはそのまま、書かれた通りに理解すればよいのだが、自分で書き直すことによって「より深く理解できた」という満足感が得られることが多い。この作業を、プログラミングにおけるリファクタリングになぞらえて私はそう呼んでいる。 リファクタリングを行なっている間は楽しいのだが、いざ出来上がってみると完成品ばかり眺めてしまい、振り返って過程を追うのはなかなか億劫になる。今回は、あえてそれを書き記してみる。 クラトフスキの流儀による順序対の集合論的コーディング\[(a,b)=\{\{a\},\{a,b\}\}\]の妥当性に関する証明を例にとる。リファクタリング前の証明は下記の通り。 【命題】\[\{\{a\},\{a,b\}\}=\{\{a'\},\{a',b'\}\}\tag{★}\]ならば\[a=a'かつb=b'\]である。
Philipp Hauer's Blog Engineering Management, Java Ecosystem, Kotlin, Sociology of Software Development Posted on Feb 12, 2018. Updated on Jun 12, 2022 Unit Testing in Kotlin is fun and tricky at the same time. We can benefit a lot from Kotlin’s powerful language features to write readable and concise unit tests. But in order to write idiomatic Kotlin test code in the first place, there is a certai
Kotlin向けMockライブラリのMockKの使い方について簡単にまとめます GitHub - MockK MockKがどんな意図で作られているかはこちらの記事で作者が語られていますのでご参照ください。 Medium - MockK: intentions MockKとは MockKはKotlin独自の言語仕様をほぼ網羅しているモックライブラリ Coroutineやobject、private関数などにも対応している優れもの 今回はCoroutineには触れませんので、あしからず。。。 公式ドキュメントにすべて書かれていますので、詳細はこちらを見てください https://mockk.io/ 今回は公式ドキュメントの内容からいくつか代表的なもの(自分がよく使うもの)を紹介させていただきます。 内容に不備等ありましたら、やさしくマサカリ投げてくださいm(_ _)m 動作確認環境について M
Ukraine has the right to return to all occupied territories and be reimbursed for all harm done by the invader. Help Ukraine to build fleet of Naval and Aerial drone with official President of Ukraine initiative ⇢ Ukraine has the right to return to all occupied territories and be reimbursed for all harm done by the invader. Help Ukraine to build fleet of Naval and Aerial drone with official Presid
呼び出し順序の妥当性検証 余計なメソッド呼び出しが行われていないことを検証する Mockito のアノテーション 複数回のモックメソッド呼び出しの結果を変化させる コールバック付きの戻り値定義 voidメソッドの振舞を定義するdoXXファミリー 実オブジェクトの動作を変えるspy 本記事は、以下の記事の続きです。 blog1.mammb.com 呼び出し順序の妥当性検証 以下のように、2つのモックがあり、それぞれのモックの add() メソッドの呼び出し順序を検証したい場合、 List firstMock = mock(List.class); List secondMock = mock(List.class); firstMock.add("was called first"); secondMock.add("was called second"); InOrder を使用します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く