タグ

Qiitaとtestに関するdecoy2004のブックマーク (6)

  • テストがないJS環境にモダンなテスト環境を導入していく - Qiita

    Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基方針 新規コードはES2015で書く 番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr

    テストがないJS環境にモダンなテスト環境を導入していく - Qiita
    decoy2004
    decoy2004 2016/01/06
    『普通だとブラウザ環境の特有なコードは動かないのだが、jsのDOM実装を噛ますことで無理矢理読み込む』
  • AssertJ版:テストでよく使う検証メソッド一覧 - Qiita

    はじめに AssertJ ~Fluent assertions for java~ JUnit でよく使う Matcher はこちらによくまとまっています。 HamcrestのMatchersに定義されているメソッドの使い方メモ 今回はこれの AssertJ 版的な位置づけで用意してみようと思います。 ただし、全ての検証メソッドを網羅しているわけではありませんので、その点についてはご容赦下さい。 バージョン

    AssertJ版:テストでよく使う検証メソッド一覧 - Qiita
  • HamcrestのMatchersに定義されているメソッドの使い方メモ - Qiita

    apply plugin: 'java' repositories { mavenCentral() } dependencies { testCompile 'junit:junit:4.11', { transitive = false } testCompile 'org.hamcrest:hamcrest-all:1.3' } >gradle dependencies testCompile - Compile classpath for source set 'test'. +--- junit:junit:4.11 \--- org.hamcrest:hamcrest-all:1.3 JUnit 4.11 はデフォルトだと hamcrest-core の 1.3 に依存している。 今回は別途 hamcrest-all を依存関係に追加するので、 transitive = fal

    HamcrestのMatchersに定義されているメソッドの使い方メモ - Qiita
  • 現場で使えるソフトウェアテスト - Qiita

    現場で使えるソフトウェアテスト Java編を読んだので要点をまとめ。 Step1 テストとは ソフトウェア開発では、様々な問題が発生するが、そのなかでよくあるのが動かない、誤動作、パフォーマンス問題人が作る上でミスは起こるのでテストが必要 テストの流れ 品質目標を立てる テスト密度(目標、上限、下限値)、バク密度(目標、上限、下限値) テスト計画 ソフトウェアテストの全体計画作成 実施スケジュール、予算、体制、環境構築手順、必要ツール利用手順、成果物の様式、バージョン管理、設計書の準備 テスト作成 期待動作、パターンの洗い出し、テスト環境構築、テストデータの作成、テストケース作成、レビュー テスト実施 作成したテストケースの実行 テスト検証 結果の確認、テスト関係者以外の利害関係者との調整(設計書管理、仕様管理、修正管理)、テスト実施者の作業管理、テスト報告のとりまとめ、テスト全体報告、再

    現場で使えるソフトウェアテスト - Qiita
  • 177bdf6352de463fdc87

    経験ゼロでもできるプログラミング現場の単体テストを読んだので、そのまとめ はじめに 著者曰く、 初めて導入する単体テストの指南書 を目指した一冊。 単体テストを書いたことが無かったり、書いたことがあっても書き方の方針が定まっていない人にはおすすめの。 逆に既にバリバリテストコードを書いてる人に、再確認的な内容になるかも。 単体テストについて基礎知識 アプリケーション開発では設計に時間がかかりすぎて、テストに時間をかけられないことがある。 致命的な障害発生する可能性がある。 とはいえすべてを想定してテストを実施することはできない。 テストケースを絞る必要がある 各テストフェーズの礎となる単体テストが重要になる 高品質なシステム ユーザーを満足させ、不安や不満をいだかせないこと システムエラー:データの破損などの心配が生まれる 応答が遅い:いらいら・二度と使わなくなる まとめてテストはダメ

    177bdf6352de463fdc87
  • jMockitがいいよ Verification編 - Qiita

    というのを使っていましたが、親戚でNonStrictExpectationsというクラスがあります。 何が違うのかというと、実はExpectationsはモックの挙動定義だけではなくExpectationsに書かれたモックメソッドが呼ばれることをチェックもしています。 なので、 を実行した時にdoAnything()の内部でfuga.getName()がコールされないとテストは失敗します。 こんな風にExpectationsで fuga.getNameは”ホゲ男”という文字列値を返す fuga.getNameが必ずcallされることをチェックする ということができます。 Verifications あらたなる旅立ち …が、ですよ。callされていることのチェックは別途明示的に書きたいものです。 そんな時にVerificationsが使えます。

    jMockitがいいよ Verification編 - Qiita
    decoy2004
    decoy2004 2014/08/19
    『callされていることのチェックは別途明示的に書きたいものです。そんな時にVerificationsが使えます。』
  • 1