LiveDataのUnitTest
ちょっとやっかいな部分もあったので、LiveDataのテストをどう書くのかまとめました。 build.gradle必要なものを追加します。LiveDataを使うので、もちろんArchitectureComponentを追加してます。 mockito-kotlin はmockitoをkotlinでいい感じに使うやつです。mockitoをそのまま使うとNull Safetyが影響したりするので、入れておくと良いと思います。 core-testing はLiveDataをテストする上で必要なものがあります。 同期処理テスト対象単純なViewModelをテストしてみます。この例だと、 fetchNameが呼ばれたらLiveDataに文字列を流してるだけです。 16行目: ここでは、Observerのmockを作成しています。mockitoを使って最後にverifyで値をチェックするためです。 17
開発現場で役立つテスト「超」実践講座
Copyright © 2004-2024 Impress Corporation. An Impress Group Company. All rights reserved.
Kotlin、MockitoによるRepositoryパターンのLocal Unit Testについて - Qiita
こんにちは、 Androidアプリエンジニアの大屋です 最近ようやくテストコードを書き始めたのでテストについてまとめていきたいと思います。 今回はRepositoryパターンのLocal Unit Testについてです。 現在、開発中のアプリですが、MVVM + Repositoryパターンのレイヤードアーキテクチャを採用していてRepositoryパターンの機構を単体テストするにはどうしたらいいのか気になったのでトライして見ました。 よろしくおねがいします💪💪💪 テスト実施用のサンプルアプリ あと、今回テストするのに簡単なサンプルアプリを用意しました。 アプリといってもSharedPreferencesに書き込み、読み込みをするだけのアプリです。 アプリはGithubリポジトリのrepository-testブランチに公開してますので参考にして下さい。ややこしいですがよろしくお願い
機械学習を使ってUI自動テストをサイト間で再利用する - DeNA Testing Blog
SWETの薦田（@toshiya-komoda）です。 今回は第3回目の記事で言及させていただいた機械学習とUIテストに関して実験的に進めている技術開発について紹介させていただこうと思います。 この記事で紹介している内容の実装はGitHubにアップロードしていますので、もし興味がある方はこちらも覗いてみていただければと思います。 こちらはTensorFlow Advent Calender 2017第７日目の記事にもなっています。機械学習の実装の中でKerasを用いてます。 とりあえずデモ 最初に以下のデモ動画をご覧いただきたいです。会員登録フォームに対する自動テストのデモです。各入力欄に適切な情報を入力しつつ、パスワード欄にだけ'weak'という不正なパスワード文字列を入力して、バリデーションで弾かれることを確認するテストです。デモでは入力欄に値を埋める部分を、Chrome Extens
既存コードをAndroid非依存なクラスに抽象化してユニットテストするための第一歩 - Qiita
これは Android その2 Advent Calendar の6日目の記事です。 はじめに ActivityやFragmentにビジネスロジックがありユニットテストしずらいコードに対して、Android非依存なクラスに抽象化することでテスタブルにする方法の紹介です。 今回はMVPアーキテクチャにすることでActivityに書いていたロジックをPresenterに抽象化してそこにテストを書いていきます。 注意点 実際に業務でアーキテクチャを選定する際は、プロダクトの規模、チームメンバーの技術力、事業の優先度などを考慮して上で決めたほうがいいので、必ずしもこのやり方がベストというわけではありません。 例えばプロダクトの立ち上げ時期はスピード優先の場合が多いので、この内容は適さない場合もあります。 やりたいこと（イメージ） 前提知識 MVPアーキテクチャとは Model-View-Prese
JUnit5で変わるテストの書き方 - きしだのHatena
JUnit5が案外よさげなので、JUnit5を使うとどんな感じでテストが変わるのか考えてみます。 実際にどこが変わったかとか、使い方自体はいろいろまとめられたブログがあるし、公式ドキュメントも読みやすいのでそちらを。 http://junit.org/junit5/docs/current/user-guide/ メソッドごとのテスト JUnit5でいいのは、Nestedですね。 いままで、いろんなメソッドを対象にしたテストが入り混じってたと思います。 import org.junit.Before; import org.junit.Test; public class PurchaseTest { @Before public void setup() { // 全体のセットアップ // purchase()用のセットアップ // history()用のセットアップ } @Test p
JUnit5とAndroidのテスト
12. JUnit5とAndroid Gradle Pluginの相性 JUnit platform gralde pluginは java プラグインを要求する ソース見たら真っ先に自動でapply してた Android Gradle Pluginは java プラグインと共存できない java プラグインが使用されていると前ページのエラー発生 どちらかがなんとかしてくれないと多分無理 きっとTest Support Libraryがどうにかしてくれる コンソールランチャーとか持ち出せば現時点でもどうにかなる かも？ 15. // プロジェクトルート or Javaライブラリモジュールのbuild.gradle buildscript { repositories { mavenCentral() } dependencies { classpath 'org.junit.platfo
JSON 文字列を JUnit / hamcrest でアサーションしたいときは hamcrest-json を使うと捗る - Qiita
package biz.k11i.demo; import org.junit.Test; import static org.junit.Assert.assertThat; import static uk.co.datumedge.hamcrest.json.SameJSONAs.sameJSONAs; /** * hamcrest-json の利用デモ。 * <p>Gradle をお使いの方なら、以下のように記述すれば OK</p> * <pre> * dependencies { * testCompile group: 'junit', name: 'junit', version: '4.11' * testCompile group: 'uk.co.datumedge', name: 'hamcrest-json', version: '0.2' * } * </pre>
ユニットテストの実行環境を用意して Visual Studio Code のエクステンションを快適に TDD する - Qiita
こんにちは @ryu1kn です。これは Visual Studio Code Advent Calendar 2016 の２日目の記事です。 Visual Studio Code (以下 VS Code) はバージョンが１に届いた頃からメインで使うようになりました。以降いくつかエクステンションを書いたのですが、今回はそれらのエクステンション開発時に必要だったユニットテストの環境準備について書きます。 TL;DR エクステンション生成時についてくるテストの実行環境は VS Code の全 API が使えるインテグレーションテスト用のものであり、起動が遅く TDD でのユニットテストには向かない コマンドラインから手早くユニットテストを実行できるようにしておくと快適に TDD できる VS Code の API を提供する vscode モジュールは、エディタ上で実行する時とコマンドラインか
ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
Google Mock：はじめの一歩
CodeZineでgtest（Google Test）を紹介したのは4年も前のこと。ひさしぶりにgtestのGitHubを覗いてみたらgtest 1.8.0がリリースされていました。この版の以前との大きな違いは"Mockのサポート"のようです。C++でMockを提供してくれるUnit Test Frameworkはそんなに多くはなかったと記憶しています。 Google製Mockの使い心地を試してみることにしました。 『Google製のC++ Unit Test Framework「Google Test」を使ってみる』（CodeZine） google/googletest（GitHub） Mockとは Unit Testは通常低いレイヤの関数／クラスから行われます。関数f()をテストするとき、f()がg()を呼んでいるなら、まずg()をテストして正しく動いてくれることを確認してからでない
Androidテストハンズオン - Qiita
これは「DevFest Tokyo 2016 秋のコミュニティ祭り！」の発表資料です。 本ハンズオンの内容 DroidKaigi2016のAndroidアプリについてEspressoを使ってUI周りのテストコードを書いていきます。 Step 0：準備編 cloneする https://github.com/cattaka/droidkaigi2016 をcloneします。 Shellからcloneする場合 プロジェクトを開き、ビルドと実行できることを確認する Step 1：テスト用のライブラリを確認する 使用するテスト用のライブラリは次のものです。 JUnit いわずとしれたJava用のユニットテストライブラリです。 Mockito テスト時に各クラスをMock可するためのライブラリです。 具体的には通信処理のように、テスト中に本番の動きをされたら困るコンポーネントの動きを差し替えるために
続・そろそろPower Assertについてひとこと言っておくか - ぐるぐる～
3年前にこんな記事をあげました。 bleis-tift.hatenablog.com 3行でまとめると、 Power Assertはユニットテストのためにほしかったものではない 欲しいのは結果の差分 誰か作って！ というエントリでした。 そしたら id:pocketberserker が作ってくれました！ github.com PowerAssertより強そうな名前でいい感じです。 Power Assertは時代遅れ、今はMuscle Assertだ！的な話かな？— 裸のWPF/MVVMを書く男(マン) (@gab_km) 2016年6月1日 MuscleAssertの使い方 このライブラリは、PersimmonというF#用のテスティングフレームワークを拡張するライブラリとして作られています。 ただ、ざっくり概要をつかむだけであればどちらも知らなくても問題ありません。 このライブラリででき
Android の Parcelable なオブジェクトの保存と復元のユニットテスト - Qiita
Parcelable インターフェイスを実装したクラスについて、Bundle などへの保存とそこからの復元の機能をテストしたい。 ちょっと調べると、Parcel に直接 Parcelable なオブジェクトを保存して復元する方法を使ってユニットテストするという方法がいくつか見つかる。 Stuff I keep Forgetting How to Do: Unit Test Your Custom Parcelable Parcelableなクラスの単体テスト - _development, これらの方法だと、復元時に YourParcelableClass.CREATOR.createFromParcel(parcel) という感じでテスト対象のクラスの CREATOR を明示的に指定する必要がある。 もうちょっといい方法にしたいなー、と思って、いったん Bundle に追加した後、その
テストクラスをAndroid Instrumentation TestsとRobolectric Tests両方で走らせる - Islands in the byte stream
（追記: このハックはライブラリとして独立させました gfx/RobolectricInstrumentation · GitHub） Robolectricは便利ですが、Oracle JREとAndroid Runtimeの微妙な挙動の違い、特にAndroid Runtimeにバグの回避するようなコードのテストができないという問題があります。 ところでRobolectricを純粋にJVM用のAndroid Frameworkランタイムとみなすと、テストクラスをほとんどAndroid Instrumentation Testsと同じように書くことができます。 Robolectricのほうがテストの実行が速いので、開発中はRobolectricを使うほうが効率はいいのですが、微妙に挙動に違いがあるので実機でもテストは走らせたいところです。そこで同じテストクラスをAndroid Instrum
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Android CI: 2016 edition
僕がテスト書け書けおじさんになった経緯とその過程でやったこと - droidkaigi-2016 // Speaker Deck
Advanced Android Espresso
組織にテストを書く文化を根付かせる戦略と戦術
http://www.sarl-tokyo.com/wordpress/?p=516