タグ

testに関するjuno_cのブックマーク (13)

  • Maven+JUnitでファイル読み込みの試験を行う。 - Qiita

    「外部ファイルを読み込むモジュールのJUnitを書きたいんすけど、指定するファイル名のパスって固定でいいですか?」と聞かれたので、「もちろんNG」と伝えた内容をメモします。 NG理由 プロジェクトファイルの位置を変えると、ユニットテストができなくなるため 他人がモジュールをチェックアウトした際に、ユニットテストができなくなるため Jenkins等のCIツールでユニットテストができなくなるため(一番イタイ) 結論 クラスローダからファイルの位置を特定してください。 Mavenプロジェクトだと、ソースファイルはsrc/main下、ユニットテスト用ファイルはsrc/test下に配置されます。 test配下のモジュールはmvn test時のみクラスパスに追加されます。そのため、JUnit試験で使用するファイルは src/test/resources 配下に置くと良いことがわかります。 外部ファイル

    Maven+JUnitでファイル読み込みの試験を行う。 - Qiita
  • テストフレームワーク mocha - hokaccha memo

    JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース)3日目のhokacchaです。Node.jsのテストフレームワーク、mochaについて書きます。 mochaはTJが新しく作り始めているテストフレームワークです。ドキュメントを見ればできることは大体書いてありますので、ドキュメントを元にどういうことができるのかを解説していきます。現時点でのバージョンは0.2.0です。 http://visionmedia.github.com/mocha/ shouldについて まずmochaでどういうことができるかの前にshouldについて解説しておきます。mochaのドキュメントには特に説明もなくshouldが使われていて、shouldでどういうことができるかわかってないと、ドキュメントを読んだときにmochaの機能なのかshouldの機能なの

    テストフレームワーク mocha - hokaccha memo
  • node.jsでこんなのもテストしたい!! という話 - Qiita

    テストフレームワークは、busterJSが一番慣れてたんですが、 部署御推薦のmochaをいっちょやってみるかー、と思っているこのごろです。 そしてついでに、 「このへんは、node.jsの場合どうテストするのがかっこいいかしら!!」 と気になっていた部分について、いろいろ調べてみました。 mochaの細かい説明については、公式その他をみてください。 mochaっていうかほとんどshouldですよね。 普通のテスト(libraryやcontrollerのテスト) テストしたいmoduleをrequireして、 shouldもrequireして、テストを書く。これが基ですね。 // テストしたいmoduleをrequire var hoge = require('../hoge'); // テスト用のライブラリをrequire (mochaの場合は、shouldがあればいいはず) var

    node.jsでこんなのもテストしたい!! という話 - Qiita
  • Python の新ユニットテストフレームワーク (or unittest2)

    これは Python3 Advent Calendar の記事です。夢はテストエンジニアです!ということでユニットテストについて書きます。 Python3 縛りとのことですが、この新ユニットテストフレームワークは Python 3.2 以降と 2.7 以降が対象です。これ以前のバージョンでこの新ユニットテストフレームワークを利用したい場合は、それぞれ unittest2py3k (3 系)、 unittest2 (2 系) というバックポートが用意されています。新ユニットテストは mock や IronPython 等の開発者としても知られている Michael Foord 氏を中心に開発されました。 >>> Python とユニットテストの歴史 Python のユニットテストは、1999 年 xUnit ファミリーの PyUnit として開発され、2001 年に公開された Python

  • shUnit2 を使ってシェルスクリプトのユニットテストをやってみた - ablog

    シェルスクリプトのユニットテストフレームワーク "shUnit2" を使ってみた - ablog のつづき。 実際に自分で作った bash スクリプトのユニットテストを実行してみた。 最初のディレクトリ構成はこんなの。 $ su - oracle $ cd /home/oracle/scripts $ tree -pfug . |-- [-rwxr-xr-x oracle oinstall] ./stop_listener.sh <-- テストしたいスクリプト `-- [drwxr-xr-x oracle oinstall] ./test 1 directory, 1 file stop_listener.sh のソースコードはこんなの。 #!/bin/bash if [ "$1" != 'exec' ]; then echo "usage: ${BASE_NAME} exec" exit

    shUnit2 を使ってシェルスクリプトのユニットテストをやってみた - ablog
    juno_c
    juno_c 2012/09/10
  • PHPUnit Manual 3.7 Japanese

    Welcome to PHPUnit! PHPUnit is a programmer-oriented testing framework for PHP. It is an instance of the xUnit architecture for unit testing frameworks.

    PHPUnit Manual 3.7 Japanese
  • nose まとめ 1 - kuma8の雑記帳

    はじめに nose を勉強しているので、自分用のまとめを公開していくことにしました。 nose とは nose は、Python 用のテストフレームワークです。 Python には、 doctest、 unittest といったいくつかのテスト方法があります。 nose は、特に利便性が高く、かつプラグインが充実しているため便利です。 まずは、インストール方法の紹介です。 インストール方法 Python のライブラリは、 インストールコマンドからインストールするの一般的です。 基的には、パッケージ名を指定することで、インストールが完了します。 easy_install $ easy_install nose pip $ pip install nose プラグイン nose を利用したテストを実施していくような環境では、同時にカバレッジを取得したり、テスト件数の増加を確認することが多いで

    nose まとめ 1 - kuma8の雑記帳
  • SQLiteのテストコードは4567万8000行! 本体のコードは6万7000行

    軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあいだで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。体のソースコードは約6万7200行(67.2KSLOC、Kilo Source Lines of Code:空行やコメントを除いた行数)なのに対し、テストコードはなんと4567万8300行(45678.3KSLOC)だと紹介されているのです! これはテストコードが体の約679倍もの大きさだということになります。 100%のブランチカバレッジ SQLiteコアのライブラリをテストするテストコードとして、以下の3つが紹介されています。 TCL Tests TCL Testsはもっとも古いテストコードで、TCL scripting lang

    SQLiteのテストコードは4567万8000行! 本体のコードは6万7000行
  • doctest de 単体テスト - s-n-kのブログ

    昨日の if __name__ == '__main__' をせっかく覚えたのに使い道がよく分からんという人のために doctest を使った単体テストについて書いてみる。doctest ってのは docstring の中にテストコードが書いてあったらテストしてくれる機能でなかなか便利 たとえばこんな感じの test.py を作る。ちなみに ''' と ''' で囲まれた間が docstring #! /usr/bin/env python # -*- coding: utf-8 -*- def testfunc(num): ''' 引数の 2 乗を返す関数。 以下テスト用のコード >>> testfunc(1) 1 >>> testfunc(10) 100 >>> [testfunc(num) for num in range(5)] [0, 1, 4, 9, 16] ''' retur

    doctest de 単体テスト - s-n-kのブログ
  • Programming Magic is under construction

    Thank you for being patient. We are doing some work on the site and will be back shortly.

    Programming Magic is under construction
  • プログラムのテストを続けるための3つの習慣 — TRIVIAL TECHNOLOGIES 2.0

    みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー テストをなかなか始められない人が多いように思います。 テストの効用として,コードのクオリティが高くなったりメンテナンス性がよくなったり,といったことはよく言われることです。また,テストのことを考えな がらコードを書くようになるので事前に十分な思考実験をするクセがついて,行き当たりばったりの開発をしなくなります。テストしやすいコードを書くように なるので,コードのモジュール性が高くなり,結果として再利用性の高い高品質なコードを書けるようになる,という利点もあります。 全部分かっていても,テストは面倒だし,テストを書くためには予備知識も必要なので,そんなことがハードルになってなかなかテスト

  • IE1, 2, 3, 4, 5, 6, 7, 8の確認が同時にできる -Internet Explorer Collection

    Internet Explorerの異なるバージョン(1, 1,5, 2, 3, 4, 5, 5.5, 6, 7, 8)を同時に起動して、確認ができる「Internet Explorer Collection」を紹介します。 Utilu IE Collection 同時起動できるIEのバージョンは、インストールするWindowsのバージョンによって異なります。 当環境(XP SP3+IE7)では、上記のキャプチャのようにIE1.5, 2, 3, 4, 5, 5.5, 6, 7, 8を同時起動できました。 ※元のIE7には特に影響はありませんでした。 古いバージョンが必要ない場合は、インストール時にチェックをはずせばインストールしないと思います。

  • Software for Automated testing | Windmill Testing Framework

    Windmill is a web testing tool designed to let you painlessly automate and debug your web application. Originating at the Open Source Applications Foundation Windmill was built to help QA keep up with the rapid release cycles of the Chandler Server Web UI (Cosmo) project. As the Cosmo client is heavy in JavaScript and AJAX functionality, Windmill makes the communication between the service and the

  • 1