こんにちは、Android アプリエンジニアの id:kk__777 です。『Inside GigaViewer for Apps』連載8回目は、出版社向けマンガビューワのアプリ版である「GigaViewer for Apps」（以下 GigaApps）のVRTから静的解析まで、Androidのテストについてお話しします。 GigaApps UnitTestの歴史と現在 概要 アーキテクチャとUnitTestの基本方針 使用しているツール モッキングライブラリ コルーチンディスパッチャの差し替え アサーション（Truth + Expect） テストツールの変遷 UIテストの取り組み VRT（Visual Regression Testing）の導入と運用 概要 Compose Preview を使った VRT GigaApps特有の難しさ UIプラグインによるPreviewの難しさ どう対
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
Rustで DI (Dependency Injection)、してますか？ 今日話題にするのはドメイン層でインターフェイスを定義してインフラ層でその実装を書くやつです。 例えばドメイン層で trait UserRepository を書いて、インフラ層で struct UserRepositoryImpl するやつです。 テストを書くとき、 struct UserRepositoryImpl はDBアクセスなどしてしまうので取り回しが悪いから、mock を作って fixture を入出力したいことありますよね。 Rustでそういうことやるなら mockall がオススメだよという記事です。 そんなに不満はないのですが、もしベターなやり方があったら記事末尾のコメントやTwitterやらもらえたら嬉しいです。 前職のFOLIO時代の同僚で現CADDiの むらみんさんの記事 に 外部通信のよう
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
2020年6月16日 TypeScript Meetup #4 にて発表した資料です。
golangでテストのためだけにinterfaceを書くのが死ぬほど嫌だったので編み出した技を紹介します。 TL;DR テスト(=mock)のためだけにinterfaceは切りたくない 型エイリアスとビルドタグを組み合わせるとinterfaceがなくてもモックが作れる この手法に必要なモックを自動生成するプログラムを作った interfaceは本当に必要なシーンで使うべき Background 現在モックを使った単体テストは一般的です。 Javaでの例を挙げると、モックしたいコンポーネントについて予めinterfaceを定義しておき、モックではそのインターフェースを実装するのが定石です。 しかしgolangのinterfaceはJavaなどのそれとは若干性質が異なるため、テスト=モックのためだけにinterfaceを書くのはオーバーワーク気味です。 そうテストのためだけにinterface
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
pytestでは、monkeypatchを使ってmockを作成できます。 Monkeypatching/mocking modules and environments — pytest documentation モンキーパッチ／モックのモジュールと環境 今回は、monkeypatch.setattr()を使って、 プロダクションコードのメソッドや関数 Python標準モジュールのメソッド を差し替え(mock化)してみた時のメモです。 目次 環境 使い方 プロダクションコードのメソッドを差し替え 標準ライブラリを差し替え 差し替え対象モジュールをimportせずに差し替え 定数の差し替え 複数の引数を持つメソッドを差し替え プライベートメソッドの差し替え 複数の戻り値を持つメソッドの差し替え 例外を送出するように差し替え プロダクションコードがimportしているモジュールの属性を差し
蛇行区間にはレールの内側に脱線防止ガードが設置される（本文とは関係ありません）。 こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。 pytest は Python のユニットテストのデファクトスタンダードです。エムスリーでも顧客向けレポートや機械学習でPython＆pytest をヘビー🐍1に使っています。 ですが、実は pytest は、意外と入門のハードルが高い。と言うのも、pytest の公式ドキュメント が、fixtureのような新概念も登場する上、詳細で分量が多いからです（しかも英語）。初心者にいきなり読ませると挫折する可能性大です 2。 そこで、とりあえず使い始めるのに必要そうな情報を日本語でまとめました。 pytest ってどんなライブラリ？ unittest や nose から簡単に移行できる 書き方がシンプル fixture モックもできる プラグイ
単体テストガイドライン¶ Pylons プロジェクトは、このドキュメントの元となった Tres Seaver によって書かれた Avoiding Temptation: Notes on using unittest effectively に倣ったユニットテスト教義をかなり厳格に守っています。 Note このドキュメントは、ほとんど排他的に 単体 テストを扱います。 結合テストまたは機能テストに対しては私たちは特別の教義を持っていません。 しかし、下記の tips の多くはその文脈でも再利用できます。 悪い単体テストを避けるための tips¶ ある人々は “don’t repeat yourself” をむやみに信じてきました (drink the KoolAid): 私たちは、ほとんどの場合にはコードの繰り返しをしないことが 美徳であることに同意します。しかし、単体テストコードはその例
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ネストの深いプログラムを書くとき、 プログラム全体で共有したいオブジェクトをどうやって引き回すかというのはいつも悩む問題です。 グローバル変数 小さなプログラムの場合は雑にグローバル変数に入れてしまうのも悪くはないですが、 プログラムが大きくなるにつれ、このやりかたはつらくなります。 シングルトン シングルトンは基本的にはグローバル変数と同じことです。 ただしファクトリ関数をうまく使えばグローバル変数をそのままつかうより柔軟な取り回しが可能になるかもしれませんが。 グローバル変数にせよシングルトンにせよプログラム全体で状態を共有しますが
https://orecon.connpass.com/event/63769/
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
テストしやすいGoコードのデザイン golang.tokyo #2 12 December 2016 Taichi Nakashima 言いたいこと 明示的であれ！ 2 whoami @deeeet / @tcnksm (GitHub) http://deeeet.com A PaaS Dev&Ops (Using go for CLI tool, API, Batch jobs) 3 OSS Tools gcli - The easy way to build Golang command-line application ghr - Create Github Release and upload artifacts in parallel Packages go-httpstat - Go package for tracing golang HTTP request latency
iOSオールスターズ2 https://eventdots.jp/event/602872
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
