プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開
Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開 Container Structure Testは、コンテナ内部でコマンドを実行することで正しい出力やエラーが帰ってくるかどうかや、コンテナ内部のファイルが正しく格納されているかなどの検証を実行できるフレームワークです。 具体的には下記のテストをサポートしていると説明されています。 Command Tests コンテナイメージ内部でコマンドを実行し、正しい出力やエラーが返ってくるかを検証する。 File Existence Tests コンテナイメージ内部に、あるファイルがファイルシステム内の適切な位置に存在しているかどうかを検証する。 File Content Tests コンテナイメージ内のファイルシステムにあるファイルのコンテンツとメタデータ
「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。
ベリサーブが月額制の機能テストツール、テストスクリプトのメンテを自動化
ベリサーブは2015年11月20日、Windowsアプリケーションの機能テストを省力化するサービス「VsAutoStudioサービス」を提供開始した。テストスクリプト通りに機能テストを実行するツールを提供するとともに、テストスクリプトの作成やメンテナンスの負荷を軽減するツールを提供する。月額制のサービスとして提供する。価格（税別）は、初期費用が20万円からで、翌月以降は月額10万円から。必要に応じて、テストスクリプトの元となるテスト項目書の作成などを請け負う。 特徴は、テスト内容を記述するテストスクリプトをメンテナンスする負担を軽減していること。ベリサーブによると、テスト項目書とテストスクリプトは、設計や仕様に変更が加わる場合を想定して、継続してメンテナンスしていくことが必要になる。ところが、テスト項目書とテストスクリプトのメンテナンスには、一定のスキルを持ったエンジニアが必要だ。 VsA
Railsのテストについての考察（暫定） [俺の備忘録]
Google+ボタン はてなブックマークボタン 更新日時: 2015年04月23日（木） 作成日時: 2015年04月23日（木） 前の記事 / 次の記事 Railsのテストについて考えまくった結果 一定の結論に達した気がした（たぶん気のせい）のでメモ。 全ての要件を漏れなくテストできればそれがいいに決まってる。 でも無理。 っていうかやる時間があったとしてもそれは果たして意味があるのか。 勝手に天から降りてくるならいいけど。 で、落としどころを探る。 フレームワークはRspecを使う。 大前提としてロジックが介在しないヶ所はテストしない。 例えばCSSが仕様通り書かれているかみたいのはテストしない。 ていうかロジックがないヶ所のテストとかただのコンペアだから不毛。 コンペアが不毛っていうことじゃなくて、 コンペアするために正解である比較対象を用意しなきゃいけないけど その用意した比較対象
gemの複数バージョンカジュアルテスト #shibuyarb - くりにっき
gemを作っていると複数のrubyのバージョンや依存gemのバージョンをカジュアルに組み合わせてテストをしたいというのがよくあると思いますが、あまりやり方が知られていない気がするのでまとめてみます 今回のエントリのサンプルプロジェクト github.com 渋谷.rb[:20150520] のLT資料 gemの複数バージョンカジュアルテスト #shibuyarb from Go Sueyoshi (a.k.a sue445) 最初にまとめ Travis CI使うのがめっちゃ楽。 セットアップ bundle gem コマンドでテストを生成 $ bundle gem multiple_version_test_sample -t --mit Creating gem 'multiple_version_test_sample'... create multiple_version_test_s
20140212 develove テスト自動化のアプローチ拡張トレンド 〜Excel項目定義手動テストから自動テストへ〜
20140212 develove テスト自動化のアプローチ拡張トレンド 〜Excel項目定義手動テストから自動テストへ〜
lxyuma BLOG
最近、goji(golang web framework)触り始めていて、 centos7のnginxからunix domain socket経由で、 gojiに繋ごうとしても繋がらなかった。 原因はすごい下らない単純な理由だったが、メモ。 ※ちなみに、よくあるsocketファイルのuser/権限の話ではない。systemdの話 事象 nginxでdomain socketを指定してbrowserアクセスすると、以下エラー web上 502 Bag Gateway nginx の error log connect() to unix:/tmp/go.sock failed (2: No such file or directory) while connecting to upstream, client: **.**.**.**, server: _, request: "GET /
JaSST Tohoku 2014 Keynote
Property-based Testing の位置付け / Intro to Property-based Testing
kintoneのJSユニットテスト最新事情 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。kintone開発チームの天野 (@ama_ch) です。 最近はJavaScriptのテストツールが著しく進歩し、日々新しいツールが登場しています。kintoneの開発もこれらのツールによって支えられています。 kintone開発チームでは、昨年末頃からテスト環境の改善に取り組み、モダンなツールセットに乗り換えました。今回は、現在のkintoneのJSユニットテスト環境について紹介します。 kintoneとJSユニットテスト 数年前からユニットテストと自動化の仕組みはあったのですが、ごく一部のユーティリティ関数に書かれているのみで、普段の開発には活用されていませんでした。 ここ1,2年ほどで テストスケルトンを生成するジェネレータスクリプトを作る テストの書き方をまとめたドキュメントを用意する MTGで「ユニットテストを書かなくていいのは小学生まで」などと煽る コードレビュー
【翻訳】そう、コントローラのテストを書くべきなのです！ - diskogs's diary
Rspecでcontroller のテストを書くべきなのかと思うことがあると思います。 Everyday Rails - RSpecによるRailsテスト入門の116ページに以下の記述がありました。 “なぜコントローラをテストするのか？ コントローラのメソッドを個別にテストするのにはちゃんとした理由がいくつかあります。 コントローラもメソッドを持ったクラスである。 この点についてはPiotr Solnicaが素晴らしいブログ記事を書いています。そしてRailsアプリケーションにおいて、コントローラはかなり重要なクラス（とメソッド）です。なので、スペック的にモデルと平等に扱うのは良い考えです。” 抜粋：: Aaron Sumner, Junichi Ito (伊藤淳一), AKIMOTO Toshiharu and Shinkou Gyo(魚振江). “Everyday Rails - RS
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
テストを書く - シンデレラは削らない
http://t-wada.hatenablog.jp/entry/debugging-tests 和田さーん！ テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。 チーム内にテストを書く習慣を持ち込んで三年、最初のうちは工数が増えるだけだ（あるある）、テストを書いても不具合がでるじゃないか（あるある）、システムテストでカバーすればいい（あるある）などという抵抗があり、それでも僕は淡々と雨の日も、晴れの日も、雪の日も、朝も夜も深夜も、終電後のオフィスでも、GW中の人気のないオフィスでも、自動テスト
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
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年間で皆さまの知識
体育の日って高速に唱えるとテストの日に聴こえる - ✘╹◡╹✘
テスト書きすぎ問題 - hitode909の日記 階層が増えるとテストが増える - はこべブログ ♨ テストと対応関係 - $shibayu36->blog; 最近書いているWebアプリは、HTTPリクエストを送ってレスポンスと状態をテストする、というテストだけ書くようにしてる。リクエストするとブログエントリを返す、というサービスだとこういう風なテストを書いてる。(HTMLを返すようにすると話が広がって説明が面倒なのでJSONを返すAPIで説明する) describe "Entry resource" do let(:params) do {} end let(:env) do { "HTTP_AUTHORIZATION" => "Bearer: #{access_token.token}" } end let(:access_token) do AccessToken.make(user
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織にテストを書く文化を根付かせる戦略と戦術
beginning
Ruby on Rails でのモックとスタブの作成(Mocha、Flex Mock、RSpecの紹介)
パスワード認証