タグ

testingに関するjimo1001のブックマーク (9)

  • テストの数を減らそう!プリキュアで学ぶPICT - Qiita

    ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか?最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても

    テストの数を減らそう!プリキュアで学ぶPICT - Qiita
    jimo1001
    jimo1001 2016/03/15
    脚注が面白すぎる
  • 5minで分かるpower-assert

    power-assert 5分ぐらいでわかるpower assert power-assert power assert assert(a === b); のような単純なアサーションのみ必要十分 Assert失敗時(テストが通らなかった時)に分かりやすい情報を表示 沢山のアサーションを使い分けしなくていいというメリット そもそも何故アサーションの種類が豊富なのか? 例) Chaiのexpect 33コもアサーションメソッドが存在 expect('foobar').to.contain('foo'); contain 含んでないから失敗した 失敗した時に何故失敗したのかを表示することが出来る どうやって動いてるの? power assert !== アサーションライブラリ コードを変換したりするのでツールに近いテストツール Work flow テストコードをpower-assert用に変換し

    jimo1001
    jimo1001 2014/04/03
  • 心地良すぎるモックライブラリ Mockito 〜その2〜 - A Memorandum

    呼び出し順序の妥当性検証 余計なメソッド呼び出しが行われていないことを検証する 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 を使用します。

    心地良すぎるモックライブラリ Mockito 〜その2〜 - A Memorandum
    jimo1001
    jimo1001 2013/10/10
  • Mockito 初めの一歩 - Qiita

    テストコードでは必須と言ってもいいくらいにお世話になっているモックライブラリ「Mockito」 最低限の使い方というか、実際よく使っているパターンを紹介します。 モックって? モックライブラリを使ったことがない方は、モックするという事自体に馴染みがないと思います。 例えば、テスト対象のクラスAが別のクラスBに依存している場合に、クラスAのテストコードなのにクラスBを初期化する処理を長々と書いたりするのは余計な手間です。もしクラスBがビジネスロジックなら目も当てられないテストコードが出来上がります。 モックライブラリでは、クラスBをクラスB自身の実装に依存しないmock(ハリボテ)として生成し、更にそのメソッドの戻り値を任意に設定するという事ができます。これにより「クラスBがこういう状態でこういう値を戻す場合のクラスAのテスト」が容易に書けます。 そしてそのモックライブラリの注目株が Moc

    Mockito 初めの一歩 - Qiita
    jimo1001
    jimo1001 2013/10/10
  • Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT

    平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識

    Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT
  • Arquillian · Write Real Tests

    So you can rule your code. Not the bugs. No more mocks. No more container lifecycle and deployment hassles. Just real tests! Alex Soto Bueno Jason Porter Andrew Gumbrecht presents: Testing Java Microservices Testing Java Microservices teaches you how to write tests for microservices in Java. You’ll learn test strategies that solve the most common issues you are likely to encounter. This practical

    jimo1001
    jimo1001 2012/04/05
  • ソフトウェアテスト - Wikipedia

    ソフトウェアテスト (英: software testing) は、コンピュータのプログラムから仕様にない振舞または欠陥(バグ)を見つけ出す作業のことである。ソフトウェアテストで見つかったプログラム中の欠陥を修正する作業をデバッグという。ソフトウェアテストに成功するとは、テストで欠陥が発見されるか、規定した試験項目にすべて合格するか、規定した品質目標に到達することである。目標とした品質には、規定した試験項目にすべて合格することもある。例えば、OS, プログラミング言語では、仕様を満たしているかどうかの適合試験を規定している。ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。ソフトウェアに仕様にない振舞がないことを保証する作業を証明といい、証明用のシステム、証明しやすい言語も多数存在している。項では動的なソフトウェアテストを中心に扱う。 ソ

    jimo1001
    jimo1001 2012/02/02
  • gihyojp - ニコニコ

    gihyojpさんのユーザーページです。

    gihyojp - ニコニコ
  • GitHub - clear-code/uxu: UnitTest.XUL, a testing framework for Mozilla add-ons.

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - clear-code/uxu: UnitTest.XUL, a testing framework for Mozilla add-ons.
  • 1