タグ

testに関するsyohexのブックマーク (36)

  • 物理サーバを選定する際のポイント – Eureka Engineering – Medium

    Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.

    物理サーバを選定する際のポイント – Eureka Engineering – Medium
    syohex
    syohex 2016/09/14
    Go 1.7 testing
  • How to test with Go - Calhoun.io

    How to test with Go If you have spent any time learning how to program you have likely run across many references to testing. Everyone talks about testing, and everyone seems to unanimously agree that you should be testing, but what exactly does that entail? In this post I will try to answer that question, first by explaining what tests are, and then I will dive into actually writing tests using G

    How to test with Go - Calhoun.io
    syohex
    syohex 2016/09/09
  • gae/g unit testing - Qiita

    golangにはgo testというunit test用の機能があります。 testを行うための testing package もあります。 しかし、gae/gでは、appengine固有の部分が動かないため利用できませんでした。 そこを解決するために以下のlibraryなどもあったのだけど、 gae 1.8.6でついにgae/gでもunit testができるようになりました! Local Unit Testing for Go gae/g unit testで重要なのは、以下の3つです。 goapp test appengine/aetest testing この3つを抑えておけば、とりあえずunit testを作り始めることができます。 goapp test goapp testはgae/gでunit testを実行するためのcommandです。 通常、golangでは、go tes

    gae/g unit testing - Qiita
  • GAE/Go+ginでHTTPリクエストも含めてEnd to Endなテストをする話 - Qiita

    はじめに GAE/Goとginフレームワークを使って ・JSONのPOSTを受け取ったら ・ginのBindJSONで構造体を作成する ・datastoreに対してその構造体を利用してPutする ・GETを受け取ったらその情報を取得する ・GETリクエスト時にくっついているパラメータをからEntityにアクセスするためのKeyIDを取得 ・そのKeyIDを用いてdatastoreから情報を取得する。 ・JSONとして値を返す という簡単なWebアプリを作ってテストしていました。 実は前回の記事でもGAE/Goのテストに関する記事を書いていたのですが、 (参照: http://qiita.com/CST_negi/items/f2fe571c5e64291d5157 ) これだと、上記例で言うところの 「・datastoreに対してその構造体を利用してPutする」 「そのKeyIDを用いてd

    GAE/Go+ginでHTTPリクエストも含めてEnd to Endなテストをする話 - Qiita
  • JavaScriptフロントエンド開発の昨今

    フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

    JavaScriptフロントエンド開発の昨今
  • Unit testing in Emacs

    All right, let’s start out with some basic unit testing. Unit testing is about testing the behavior of a specific function. A good rule of thumb is that if an Elisp function is interactive, it should most likely not be tested with a unit test, but rather with an integration test. The reason is that the unit test will not use the function as it is supposed, via M-x or a key binding, but with an exp

  • Haskellの単体テスト最前線 - あどけない話

    この記事の最新版は、githubで管理されています。 これはHaskell Advent Calendar 2012の5日目の記事です。 Haskellで作成したパッケージに対して、単体テストを書くための最新情報をお届けします。 要約 要点は4つです。 利用者に見せたい振る舞いは、doctest で書く 利用者に見せたくない振る舞いは、hspec で書く テストを自動化するフレームワークとしては Cabal を使う doctest でも hspec でも、純粋なコードに対しては、できるだけ QuickCheck などの性質テストを書く この記事で一番伝えたいのは、3) です。例題としては、Base64 という符号化を取り上げます。Base64 は知っていると仮定して話を進めますので、知らない人はあらかじめ Wikipedia の Base64 の説明でも読んで下さい。 この記事で利用するコ

    Haskellの単体テスト最前線 - あどけない話
  • テストの自動実行あれこれ - Qiita

    この記事は、Ruby開発環境 Advent Calendar / Jul.の3日目の記事です。 テスト自動実行のススメ TDDを実践していると、Red -> Green -> Refactoring をリズムよくループさせることが重要となります。 そこで、コードの変更を検出してテストを自動で実行するようなツールによるサポートがあるとものすごく捗ります。 古くは autotest(ZenTest) のような gem を利用して実現していました。 今でも「ruby 自動テスト」とかでググると autotest に関する昔の記事が上位に出たりします。 autotest は定まった環境では非常に便利なのですが、 少し違ったことをしようとすると、変更が非常にめんどくさく、柔軟性に欠けていました(今もそうかは知りません)。 そこで、監視対象とそれが変更された時に何をするかがDSLで簡単に書けるような

    テストの自動実行あれこれ - Qiita
  • クライアントサイドJSでもサーバーサイドJSでもうごくテストを書く - Articles Advent Calendar 2011 Amon2

    こんにちは! tokuhirom です。日曜日ですね! 今日は Test トラックにかこうとしたけど Perl 関係なさすぎて自重したネタをかこうかとおもいます。 さて、Amon2 の重要なパーツといえる strftime.js ですが、こちらもちゃんとテストしなくてはなりません。strftime とかいちばんテストしやすいうえにバグりやすいのに、テストしてないライブラリがおおくてなさけなくなる今日この頃ですからね。 テストライブラリの選定 さて、Perl ならば Test::More をとりあえずつかっておけばいいのですが、JS の場合はどれをつかうべきかなやむところです。JS の場合、いろんな人がオレオレなテストフレームワークをだしててややこしいことこの上ありません。 こういう場合、Perl でも JavaScript でもライブラリの選定方法はかわりません。譲れない機能、ライブラリの

    クライアントサイドJSでもサーバーサイドJSでもうごくテストを書く - Articles Advent Calendar 2011 Amon2
  • Linux愛好者の独り言 Cutterのとても簡単な使い方

    Linux愛好者の独り言」は,Linuxやプログラミングの,楽しさや初心者向け情報を配信するBLOGです。 CutterはC/C++用の単体テストユニットフレームワーク(所謂xUnit)だ。 評判が良いので,以前から使いたかったのだが,いかんせん,家のチュートリアルが丁寧すぎてわかりにくく,使い方がわからなかった。 このチュートリアルでは,automake等を用いた格的な使い方が書かれているので, てっきりCutterを使う時はいつもこのくらいの準備が必要なのかと思っていた。 ほんのちょっと,テストコードを書いて開発の補助にしたいだけなのに,いちいちMakefile.amだのconfigure.acだのを作るのは面倒だ。 (これが面倒でない人間はIDEなんて使わないだろう) 毎度,このチュートリアルに従うくらいなら,cxxTestでもを使うほうがましだと思った。 だが,どうやら,

    syohex
    syohex 2011/11/15
  • 'or BAIL_OUT' idiom - "><xmp>It's in beta

    ok(), is(), and other functions exported by Test::More returns 1 if succeeded, 0 otherwise. So you know the idiom using this return value ok($foo) or diag Dumper($stuff);And today, i introduce a "subtest $name => sub { ... } or BAIL_OUT" idiom. Sometime, you may want to stop the test script after failing, so I recommend this idiom. subtest "my failing test" => sub { ok $thing; } or BAIL_OUT;Then

  • にひりずむ::しんぷる - 最近の .proverc

    prove はカレントの .proverc ってファイルにオプションを書けるので色々と書いておくと便利。 最近は、以下のようにしてる。 --exec "perl -Ilib -It/lib -MTest::Flatten -MTest::Name::FromLine" --color --merge --timer -w こんくらい書いておくとまぁ大体いい感じになる。

    syohex
    syohex 2011/11/09
    テスト用のモジュールは t/libに置いた方がいいのかな.
  • App::Prove::RunScriptsで快適テスト生活

    公開場所 CPAN github 開発動機 WebアプリケーションのデータストアにMySQLを利用している場合、テストでTest::mysqldを使っていると思います。 しかし、各テストファイル毎にmysqldを立ち上げていると、テストファイルが増加した際に、mysqld立ち上げのオーバーヘッドが問題になります。 これを解消すべく作成しました。 既存の解決策 にひりずむ::しんぷる make test で Test::mysqld を永続化させる方法 Craftworks Tech Blog - Branch Test::mysqld を別ウィンドウで立ち上げたら開発時の prove が快適過ぎる件 問題点 Module::Install::TestTargetは色々と便利なこともできるが、単純にテスト実行前にTest::mysqldを叩くだけには大げさ過ぎる 裏で先に立ち上げておくのは正

  • 米AMD、さまざまなケースに対応するテストインフラ「Tapper」をオープンソースで公開 | OSDN Magazine

    米Advanced Micro Devices(AMD)がオープンソースのテストインフラ「AMD Tapper」を公開した。OSや仮想化も含めたさまざまなテストのためのオープンソースインフラで、QA部門における計画から実行、レポートまでを含めたテストライフサイクルの継続的な支援を目的とする。 TapperはAMDドイツに持つOperating System Research Centerが中心となって開発を進めており、ソースコードは二条項BSDライセンスの下で公開されている。コア部分はPerlおよびCPANで提供されている各種ライブラリで作成されており、Test Anything Protocol(TAP)サポート、データベース非依存、プログラミング言語にとらわれないテストなどを特徴とする。独立したモジュールを提供することで、さまざまなQA要求に対応するとしている。 Tapperの特徴と

    米AMD、さまざまなケースに対応するテストインフラ「Tapper」をオープンソースで公開 | OSDN Magazine
    syohex
    syohex 2011/04/30
  • Csmith

    Csmith is a tool that can generate random C programs that statically and dynamically conform to the C99 standard. It is useful for stress-testing compilers, static analyzers, and other tools that process C code. Csmith has found bugs in every tool that it has tested, and we have used it to find and report more than 400 previously unknown compiler bugs. Publications and Presentations Finding and Un

    syohex
    syohex 2011/04/15
    Cコンパイラランダムテスト
  • Shibuya.jsに行ってきた - すぎゃーんメモ

    Test.jsを聴きにいきました。 http://shibuyajs.org/articles/2011/02/28/test Shibuya.js - Test.js : ATND 以下、自分メモ。敬称略です。 var memo = { main_talk: [{ title: 'さいきんのCUIでのJavaScriptテスト', speaker: 'hotchpotch', contents: [ // 遅刻したので前半聴けず…, 'Johnson: SpiderMonkeyをRubyから JSからRubyをつかえる', '応用 Envjs, JSDefferedのあわせ技', '思った以上に使える ふつうのJavaScriptなら動く', 'エンドツーエンドテスト 全体の振る舞いをテストしたい', 'HTMLの取得、Ajaxの実行', 'Capybara: Ruby CUIからAja

    Shibuya.jsに行ってきた - すぎゃーんメモ
  • さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料 - 川o・-・)<2nd life

    日行われた Shibuya.js の発表資料をアップしました。 さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料 View more presentations from hotchpotch JS のテスティングフレームワークのおおざっぱな説明や JavaScript テストにおける問題、それについての解決方法の一つ、CUI でのテスト、Envjs、エンドツーエンドテストにおける JS / Ajax のテスト、終わりにちらっと Phantomjs の話があります。 スライドの最後にあるように、やはりまだコレだ!という JS のテスティングフレームワークは存在しなく、今後 JS のテストは『僕らが書きたいテスト』をどれだけ簡単に書ける・書く手法が確立されるかによって流行廃りは決まってくるんじゃないかなぁ、と思ってます。そのうちの一つがスライ

    さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料 - 川o・-・)<2nd life
  • Test::Mock::Guard Released - 日向夏特殊応援部隊

    さっき nekokak さんと xaicron さんにそそのかされて Test::Mock::Guard ってモジュールを書いてみました。 そもそも Perl には Test::MockObject と言う汎用の Mock モジュールがあるんですけど、あれこれ余計な機能がたくさんついてたり Mock 化すると多分元に戻せないと言うのがあってもっとシンプルな奴がほしいなと思って作ってみた次第です。SYSNOPSIS のコピペですけど、 use Test::More; use Test::Mock::Guard qw(mock_guard); package Some::Class; sub new { bless {} => shift } sub foo { "foo" } sub bar { 1; } package main; { ### このスコープでは Mock 化されてる my

    Test::Mock::Guard Released - 日向夏特殊応援部隊
    syohex
    syohex 2011/03/09
    実装を確認してみる
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか?

    グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか? グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl

    グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか?