QUnitの基本的な使い方 - but hopeful
[追記] 2013/9/1 三年前の記事が未だに読まれているようなので、一応書いておきますが、あれから色々変わってもっと良いものも出ています。 QUnit でも別に問題はないですが、今から QUnit を使うよりは http://visionmedia.github.io/mocha/:title=mocha] とかの方が個人的にはお勧めです。とにかく、今は色々あるのでもっと別の選択肢調べて見ることを個人的にはおすすめします。別に QUnit は使わないほうが良いとは言いません。 JavaScriptのテスティングフレームワークはいろいろありますが、自分は今主にQUnitを使っているので、少し使い方をまとめて見たいと思います。 [追記]今回作成したソースを上げました。ninja.js QUnit とは QUnitはもともと、jQueryをテストするために開発されたJavaScript Un
審議前に売買契約の手順資料 財務省、森友側に渡す：朝日新聞デジタル
学校法人「森友学園」（大阪市）の国有地売却問題で、財務省の佐川宣寿（のぶひさ）理財局長は２１日の衆院国土交通委員会で、小学校開設の適否を判断する大阪府の審議会の開催前に、近畿財務局の担当者が売買契約締結までの手順を書いた資料を学園側に渡していたことを認めた。 共産党の宮本岳志氏から２０１４年１２月１７日時点で近畿財務局が作成した資料を示されて答えた。 宮本氏が学園側から入手したという資料には、「森友学園が土壌汚染及び地下埋設物除去工事実施」「森友学園と財務局・航空局との間で有益費（地下埋設物の撤去費）に関する金額協議」など学園側の計画に即し、国有地の貸借から売買に至るまでに必要な申請書類や手順、時期が記されていた。佐川氏は「手続きが円滑に進むように参考として渡した」と説明した。 宮本氏によると、入手資料のなかには申請書類の案文を学園側に指南するものもあり、「校舎建設等に多額の初期投資を必要
習主席側近の疑惑語ったら、突然中止に 米政府系の番組：朝日新聞デジタル
米国滞在中の中国人政商が１９日の米政府系放送局ボイス・オブ・アメリカ（ＶＯＡ）の中国語チャンネルのネット番組で、習近平（シーチンピン）国家主席の側近で「反腐敗」運動を進める最高指導部メンバーの疑惑を語ったところ、番組が突然中止となった。中国当局が圧力をかけたとの見方が出ている。 出演したのは投資会社の実質経営者、郭文貴氏。番組で「習国家主席の意向を受けた公安部の現役幹部から、王岐山（ワンチーシャン）・中央規律検査委書記ら高級幹部とその家族について調べるよう求められた」などと語った。インタビューは生放送で３時間の予定だったが、１時間２０分を過ぎた時に司会者が「放送を中止しなければなりません」として打ち切ってしまった。 関係者によると、放送数日前に中国外務省が北京のＶＯＡ記者に今回の放送をやめるよう働きかけていたという。ＶＯＡ側は打ち切りについて「もともとインタビュー部分は１時間の予定だった。
GitHubで署名されたコミットにバッジが表示されるようになったので設定してみる - Qiita
まずはこちらの画像をご覧ください。 GitHubのコミット履歴ですが、コミットのSHAの左に見慣れないものが表示されていますね。 クリックするとこのような情報が表示されます。 実は、2016/4/6からGitHubはGPGによりデジタル署名されたコミットやタグにバッジを表示するようになりました。 この記事はその設定ガイドです。私の環境はWindowsですが、すべてコマンドラインとブラウザ上での操作なのでMacやLinuxでも同じように行えます。 1. GPGのインストール Git for Windowsを使っている場合は、GPGが同梱されているため追加のインストールは不要です。 それ以外の方はパッケージマネージャを使ってインストールするか、こちらからツールをダウンロードします。トップにはソースコードのリンクが掲載されており、バイナリのダウンロードリンクは下のほうにあります。 画面の指示に従
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
単体テスト盲信してる皆様へ
そもそも意味あるのかちゃんと考えてる？ 「単体テストを書けばバグが減ります！」 「単体テストのお陰で精神的安定を保てます！」 馬鹿じゃねーのかｗ？ テストコードのメンテなんてデバッグの手順書メンテしてるのと大して変わらねーよｗ その単体テストが本番と同一の動作をテストできてる保証はねーって気づけボケが 本番と同じ動作をテストしたかったらデバッグしろよ なんで別のコード書き始めちゃうの？無駄じゃん馬鹿じゃん それと「テストコードがあるから安全です」なんて寝言まだ言ってるの？ プロジェクトが進むにつれソースも依存ライブラリも変化する以上 いつも同じ結果になるわけじゃねーだろが、（保守しないって選択はあるけど金入ってこないだろ） 本番でもテストコード動かしますってやつら以外無理して単体テスト書く必要ないんじゃねーか？ お前らが欲しいのは軽いデバッグモードであって単体テストじゃねーだろ？ 工数削っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
