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年間で皆さまの知識
Node.gs： Node.js スタイルでの Google apps script 開発手法 - Qiita
Google apps script のオリジナル・オンライン開発環境は、小さなプログラムをちゃちゃっと書いては捨てて動かすのにはとても便利ですが、ある程度大きなソフトウェアを開発・運用するとなるとそのままでは難しくなります。 特に Google apps（今は G-Suite ですね）を利用した業務システムの開発・運用をしている人は、業務システムは継続改善がつきものですし、苦労されているのではないかなあ・・・と思います（私もです！）。 そこで本稿では、Google apps scriptアプリケーションを Node.js のように複数モジュールで構成し、テストし、構成管理しながら開発する一連の手法を紹介します。 このフローを支えるツールもいくつか公開済みなのですが、実際にはまだ完全でない部分もあります。そういう意味では本来この記事はまだ早いのかもしれません。ただ業務の片手間でやっていてち
Vue.jsのユニットテスト
Vuex is used to manage state in a Vue application. Components dispatch actions that commit mutations to update the central state object. Computed properties are used to retrieve parts of the state and watch for changes. Two-way bindings with v-model trigger mutations to update state values. Maps are used to generate computed properties for multiple state properties.
一休.com で 1 年半の間に取り組んできた改善内容について - 一休.com Developers Blog
この記事は一休.comアドベントカレンダー2017の 8 日目です。 一休.com の宿泊開発基盤のお手伝いをしている id:shiba-yanです。 はてなインターン時代の縁で naoya さんから声をかけていただき、基本フリーランスですが一休で週に 3 日ほどの作業を 2016 年 4 月から行っています。 最近は shibayan とも一緒に改善を進めている 4ヶ月の間に一休.comで起きた変化 - zimathon blog 2016 年 4 月末から現在までに、一休社内でどのようなことに取り組んできたか、公開できる範囲で思うままに書いていきます。長いです。 ユニットテスト基盤 新しいメールテンプレート メール配信基盤 宿泊クラウド移行 移行方法の調査・検証 実行環境の調査・検証 アプリケーションの分離と整理 AppVeyor での CI / CD 本番環境の移行 その後の運用 宿
初めての自動テスト
Webシステムの自動テストを始めたい方を対象に、自動テストの考え方やフレームワークを解説する書籍です。テストのピラミッドやユーザーインターフェイステストの概念など、基礎的な事柄から、レガシーシステムへのUIテストの追加、RESTfulなWebサービスのテスト、ブラウザ上のJavaScriptの挙動をユニットテストでテストする方法など、実践的な事柄までを豊富なイラストとサンプルを使って分かりやすく解説します。さらにテストファーストやモックの活用法、テスターに向けた自動テストのためのプログラミング基礎知識なども詳述。自動テストを書くためのノウハウを網羅した本書は、自動テストをマスターしたいエンジニア必携の一冊です。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では
よいユニットテストを書くには
テストを小さくする。適切なツールを使う。プログラマとテストがペアになる。これらは、よいユニットテストを書くための、Adrian Bolboaca氏からの提案だ。 ユニットテストは、プログラミングとテストが混ざり合ったものだ。プログラマは、テスタと共に作業することで、お互いに学び合い、視野を広げることができる。 Adrian Bolboaca氏は、Mozaic Worksの組織と技術に関するコーチであり、ヨーロッパテストカンファレンス 2017において、様々なタイプの自動テストについて話す予定だ。 InfoQは、このカンファレンスについて、Q&A、要約、記事で扱う。 [ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。 私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十
Increments社を退職します
昨年の5月からIncrements社でQiitaの開発に従事していましたが、今月末をもってIncrements社を退職します。在籍期間は10ヶ月。今日が最終出社日です。 Incrementsでは、Qiitaの機能追加開発を主に担当していました。Qiita Blogには、僕がリリースしてきた機能が掲載されています。 yoichiroがIncrementsにJOINしました - Qiita Blog Email Markupに対応しました - Qiita Blog 外部リンクへの属性が変わります - Qiita Blog (僕が実作業者) Qiita Organizationで組織の紹介などを書ける「About」の提供を開始しました - Qiita Blog details,summary要素に対応し、投稿内で指定箇所を折りたためるようになりました - Qiita Blog 「Qiita Ad
オレの最弱のES6開発環境 - Qiita
ブラウザのES6サポートが急速に良くなってきています。社内ツールとかElectronとか、ブラウザの普及率を気にしなくていい環境ならそろそろ使えるのではないかと思って調べたり試してみたりしています。 更新 https://caniuse.com/#search=es6 http://kangax.github.io/compat-table/es2016plus/ これを見るともうほぼ実装は完了していますね。Node.jsも対応していますし使えるブラウザが限定できるならもはや変換なんかしなくても大丈夫。注意点としては以下の2つ。 IE11は渋い ES6 modulesはまだまだ ソースをES6で書いて、結果もそのままES6という手抜き開発に使えるツールのメモです。手抜きなので、おそらく経年変化の影響はほとんどないはずです。対象としてはブラウザだったり、ElectronでのSPA開発です。
Scala Puzzlersという本の翻訳をしていました - たけぞう瀕死ブログ
ここ二ヶ月ほどScala Puzzlersという本の翻訳をしていました。邦題は「Scalaパズル 36の罠から学ぶベストプラクティス」で翔泳社さんから2月頭に発売になります。 Scalaパズル 36の罠から学ぶベストプラクティス 作者: アンドリュー・フィリップス,ネルミン・セリフォヴィック,竹添直樹,島本多可子出版社/メーカー: 翔泳社発売日: 2016/02/05メディア: 単行本（ソフトカバー）この商品を含むブログを見る 以前から書籍の翻訳を一度やってみたいと思っていたのですが、技術的に自分の得意かつモチベーションのある分野で、分量や内容的に手に負えるもので、さらに商品として成立する可能性のあるものという条件を満たすタイトルがなかなか見つからなかったのですが*1、今回幸運にもScala Puzzlersの翻訳をやらせていただくことができました。 作業はシルバーウィークあたりから本格的
JUnit5はどこに向かうのか？ | DevelopersIO
この表から解るように、一部の機能を除けばJUnit4の機能は継承されています。 したがって、JUnit4を理解していれば継承された機能をJUnit5に移行することは難しくないでしょう。 最初は多少の混乱はあるかと思いますが、すぐに慣れるレベルかと思います。 逆に、新しくJUnit5からJavaのユニットテストに入るのであれば、JUnit4の制約がないことは良い材料です。 特に、構造化テスト（ネストクラス）の時、JUnit4ではネストクラスをstaticクラスにすることを強いられていました。 これは、テストクラスをテスト毎に作成するという制約があったためです。 この制約がある以上、テストクラスからアウタークラスのインスタンス変数にアクセスできませんでした。 ユニットテストではテスト毎にテストインスタンスを作成することが原則なので、この制約は仕方ないと考えても良いでしょう。 しかし、テストがネ
ソフトウェア開発におけるデザイン視点の変化 - arclamp
2015/11/14（土）に開催されたJavaOne2015報告会で話をしてきました。資料は以下。 この資料を作る中で気づいたというか、思ったことは、この20年でソフトウェア開発におけるデザインの視点が変化しているな、ということです。 ユニットテストとDIコンテナが変えたもの ユニットテストは衝撃的なものでした（はい、僕も@t_wadaの薫陶を受けたのです）。 ユニットテストを端的に説明するなら「自分で書いたコードを、自分のコードで確認する」ということですが、いわゆる「テスト」というよりは「実装技法」であると考えたほうがよいと思っています。 （それはTDDの事だとか、UATとしてのテストコードは別の意味があるとか、そういう話を含めたとしても、僕はユニットテストを実装技法だと理解しています。話がややこしいですが、「単体テスト」はテストでしょうね） もちろん、DIコンテナも大きな変化でした。「
テストを書くか書かないかの判断の話
writing_unit_test.md ユニットテストでテストを書くか書かないかの判断の話 お題 メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか テストとは まず、基本の考えとしてなぜテストをするのか？というのがあります。 テストとは、エラーをみつけるつもりでプログラムを実行する過程である。(via ソフトウェアテストの技法 [Glenford J. Myers]) という言葉のとおり、最小の手間でプログラムのエラーを見つけ出そうとする試みがテストです。裏を返せば、エラーが見つかる可能性が低いのにすべてのことを試すのはテストではありません。 判断するときの論点 いくつかこれを判断するときの論点があります (Boolean に限らず、「そのテストは必要か？」と考えるときの観点ともいえ
社内JavaScript勉強会で作ったコンテンツまとめ - Qiita
はじめに 弊社で実施している社内向けJavaScriptの勉強会のコンテンツまとめです(最近はやってないのも上げてる)。対象は独学でJavaScriptを少し触ったことがあるけど企業でやったことはない、くらいのレベルの人です。このコンテンツを作っている筆者も1年くらいしかJavaScriptを触ってないので怪しい所もあると思いますが、社内でのJavaScript教育に困っている方の参考になればと思います。 ちょっと一部古かったりするので、Issueでも立てて下さい。気が向いたら直します。 ES2015(ES6) JavaScriptを書く上でスタンダードになりつつあるトランスパイラBabelを使用したコーディングについて学びます。ES2015の記法について全て網羅しているわけでなく、今すぐ使える簡単なものを優先して開設しています。ES2015の構文を使うことで何が楽になるのか、という点を重
React入れたらCasperJSのE2Eテスト壊れたのでPhantomJS2入れたらPhantomJSのユニットテスト壊れたのでwebdriverioでE2Eテスト書き直した話 - マルシテイア
これまで VanillaJS / jQuery で頑張ってたプロジェクトに React 入れて、Reactは最高！などと言っていたのだけど、E2Eテストが落ちている事に気づいた。 落ちたテストで画面キャプチャしたりして調べた結果、Reactコンポーネントを描画するところで落ちていた。 どうやらPhantomJS1系で見られる現象のようだった。 e2e - CasperJS で Reactjs のサイトをテスト - Qiita E2EテストにはCasperJSを使っていた。 Casper の dependencies は "phantomjs": ">=1.8.2" となっている。 PhantomJS の謎な挙動にはユニットテストでも散々苦しめられていた。 既に polyfill 幾つか入れて対処していたのだけど、良い機会なので別の道を模索してみよう、という話になった。 頑張ってPhanto
「スタブ」と「モック」は全然違うものなんですよ - uehaj's blog
「スタブ」と「モック」は全然違うものなんですよう、という話は前からされてますが、世の中にたくさんの誤解があふれている。ファウラー氏の記事もわかりにくいわい！！！頭のいい人に解説させてはダメだ！（暴論）。 つーことで上の考え方を私の言葉で述べます。 「スタブ」と「モック」は違います。何が違うかといいますと、目的が違います。何の目的かというと、試験の目的です。 んでね、混乱の原因の一つは「スタブオブジェクト」「モックオブジェクト」という使うモノを見てては、この目的の違いが分からないということです。日本刀とマグロ切り包丁を見ていても、両者が違うことがわからない。目的と照らし合わせてみて始めて違いがわかるんです。 モックについて言うと「オブジェクト間の相互作用を見るためのテスト」をするときに用いるのがモック。以上。それ以上でもそれ以下でもない。便利さの度合いも試験の手軽さもスピードも関係ない（直交
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://ubiteku.oinker.me/2015/07/21/tdd-is-dead-long-live-testing/
https://ubiteku.oinker.me/2015/07/27/why-most-unit-testing-is-waste/