[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

テストに関するramtigaのブックマーク (29)

  • うちのチームのプログラマーはなぜテストがうまいのか - CAT GETTING OUT OF A BAG

    うちのチームのプログラマーはテストが好きかどうかは分からないけど「これよく見つけたなー」と思うようなバグを見つけてくるからテストがうまいと思う。で、なんでうまいのか考えているのだけど「毎日1時間、システムレベルのテストをしている」のが、うまくなる要因の一つなんじゃないか。— miwa (@miwa719) 2019年6月24日 医用機器(自社製品)のソフトウェア開発に従事して、あと数年で30年になります。いろんなチームに所属し、多くの開発者と一緒に仕事してきましたが、現在所属しているチーム(うちのチーム)のプログラマーはテストがうまいです。プログラマー時代の自分と比較してもそう思いますし、『ソフトウェアテスト』という側面から製品開発を考えられるようになった今の自分から見てもそう思います。いいバグを見つけたなぁ…(素晴らしい)と思うことが多々あります。 うちのチームのプログラマーはなぜテスト

    うちのチームのプログラマーはなぜテストがうまいのか - CAT GETTING OUT OF A BAG
  • 休日個人開発で学ぶテストコード! 画像に“集中線”を合成するツールを作ってみよう - エンジニアHub|Webエンジニアのキャリアを考える!

    休日個人開発で学ぶテストコード! 画像に“集中線”を合成するツールを作ってみよう プライベートでも何か作りたい! そんなときの「今日からはじめる休日個人開発」シリーズ、第二弾はテストコードを書きながら簡単なMVCモデルの画像加工ツールを作ってみましょう。好きな写真に集中線を合成できます。 皆さん、プライベートで何か開発していますか? 「何か作りたい」という気持ちはあるものの、いまひとつ何から始めたらいいのか分からず、動けないままの人も多いと思います。 そんな皆さんのために、「仕事以外にも休日に個人で気軽に何かを作ってみよう!」という企画の第二弾です。今回は、第一弾で用意した開発環境を使って、画像を加工するツールを実際に作っていきます。 せっかくですので、ただ作るだけではなく、テストコードも一緒に書いてみましょう。最近は、CI(継続的インテグレーション)やCD(継続的デリバリー)も一般的にな

    休日個人開発で学ぶテストコード! 画像に“集中線”を合成するツールを作ってみよう - エンジニアHub|Webエンジニアのキャリアを考える!
  • テスト書きすぎ問題 - 銀の人のメモ帳

    少し前までiOSとかAndroidのネイティブアプリとかゲームアプリとかしか開発してなくて、テスト真面目に書いたことが無かった。 テスト真面目に書いたこと無くても、テスト書いたほうが良いとは思っていて、MockとかStubとかテストデータの生成と破棄とかを考えると安い受託開発で納期も少ないしディレクターとかに手動テスト任せたほうがコスト低いよねみたいな感じだった。あとは身近にスマホアプリのテストをしっかりと書いてきた人が居なかったのもテスト真面目に書いてなかった一因ではあると思う。 この前までcocos2d-xでゲームを開発してて、最初はtemplate使って頑張ってDIみたいなことしてみたりしたけど、めちゃくちゃコスト高いし、C++製でandroid-nkdで問題なくビルド出来る良さそうなMockとかStubとかDIとか出来るライブラリが無くて結局通信とかデータとかが絡まない部分のテスト

    テスト書きすぎ問題 - 銀の人のメモ帳
  • ノンプログラマーが3ヶ月でWebサービスを作ってみた - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ノンプログラマーがはじめてWebサービスを作ってみた記録です。 2016.3.28 追記: リリース1年後について書きました。 はじめてのOSSリリース記 〜なぜ無料でソースコードを公開するのか? 自己紹介 趣味でたまにプログラムを書く程度のノンプログラマー業は SHIFT( http://www.shiftinc.jp ) という会社でテスト自動化エンジニアをしています。 20代最後の年に何か新しいことを!と思い立ち、勢いでWebサービスを作ってみました。 作ったもの Chibineko - 世界で最もシンプルなテストツール h

    ノンプログラマーが3ヶ月でWebサービスを作ってみた - Qiita
  • 【Rails】RSpecと三種の神器でらくちんWeb APIテスト - Qiita

    はじめに 3月頃,『【Rails】RSpecでWeb APIのテストでハマったところ①』という初心者丸出しな記事を書きました. あれから9ヶ月ほど,お仕事としてRailsに触れたりしたため知見・スキルも向上してきたと思います. そして今,前述の記事を見直したところ恥ずかしくて顔を覆いたくなる感じになったので改めてWeb APIのテストについて書いていきます. APIのテスト? そもそもWeb APIのテストはどこに書くの?ってところからですが… Controller SpecではなくRequest Specに書いていきます. Use RSpec Request Specs Since we’ve established that we’ll be using Rack::Test to drive the tests, RSpec request specs make the most s

    【Rails】RSpecと三種の神器でらくちんWeb APIテスト - Qiita
  • TDDを諦めることと、RSpecをやめること - 高柴ラボ

    2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の

  • GolangTestNight(Gunosy.go #10)に参加してきた - 絶品ゆどうふのタレ

    http://gunosygo.connpass.com/event/8485/ Goのテストに関する話を聞いてきました。 テスト周りは正直まだまとめ記事読んだ程度しかキャッチアップできていなかったので、周囲がどんな方針でテストしているか、とかも含めて勉強したいと思っていたところ、ちょうどいいタイミングで勉強会があったので参加してきました。 まとめと感想 先に。 みんなわりと、素直にGoの用意した仕組みに則ってやってる。 とはいえAssertionないのつらいよね、とか、mockの再実装辛いよね、というのは皆思ってるみたい。 Web APIで使ってます、というパターン多いみたい。 最終的に懇親会ではインフラの方とopsworksの話で盛り上がってた(ノ∀`) というわけで、以下メモ。資料URLが見つかったものは貼ってます(`・ω・´) Goのテストの基 t_matsuwitterさん そ

    GolangTestNight(Gunosy.go #10)に参加してきた - 絶品ゆどうふのタレ
  • Everyday Rails - RSpecによるRailsテスト入門

    みなさんはこんなふうにRailsアプリケーションを作ったことはありませんか?たとえば、ブラウザをポチポチとクリックするだけでテストを終わらせて「たぶん大丈夫」と思い込んだり、「とにかく全部うまくいきますように」とただ祈るだけだったり……。 心配しないでください。それは誰もが通る道です。アプリケーションのテストやテスト駆動開発はRails開発における重要なトピックですが、巷の参考書を見ると適当な説明で済ませているものも多かったりします。書「Everyday Rails - RSpecによるRailsテスト入門」では、どのようにして私がそうしたテクニックを身につけたのか、そして、どのようにしてコードの信頼性を上げ、ブラウザ上で延々とテストしなくて済むようにしたきたのかをみなさんに説明します。 対応バージョンについて2024年1月のアップデートで、書のコンテンツをRails 7.1とRSpe

    Everyday Rails - RSpecによるRailsテスト入門
  • Rails3.2 + RSpecで楽しいTDD(導入編)

    さて、標題にはTDDと書いてますが実際にはコード書いてからテスト書いてたりしてます。 手元でちまちま書いてるアプリもさすがにテストも無しではいかんだろうということで まずは手元にあるコードのカバレッジが100%となるテストを書き、 その後次に何か乗っける時からはテストから書いていきたいと思います。 というわけで今回はテスト環境の導入編から。 この記事で前提とする環境は ・CentOS6 ・Ruby on Rails 3.2.2 ・Ruby 1.9.3 p-125 ・MySQL となっています。 (1)テストに必要なGemの導入 app_root/Gemfileに以下の記述を追加 gem 'rspec-rails' gem 'simplecov', :require => false #gem 'simplecov-rcov', :require => false gem 'spork' '

  • これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE

    和田卓人さんによるテスト駆動開発問題解説の寄稿です! バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中! by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上

    これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE
  • 巨大な(あるいは、汚くて邪悪な)コードの泳ぎ方 - mizchi's blog

    ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニア当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん

    巨大な(あるいは、汚くて邪悪な)コードの泳ぎ方 - mizchi's blog
  • テスト書きすぎ問題 - hitode909の日記

    テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

    テスト書きすぎ問題 - hitode909の日記
  • RSpecまとめ(2)~Mock(double/stub/mock)~ - web-k.log

    前回はRSpecの基メソッドについてまとめました。今回はMockについてまとめます。 テストダブルとは テスト対象が依存しているモジュールやリソースの代役のこと。結合テストのような複雑な環境を事前に用意せずとも目的の機能をテスト可能となるように振る舞いをシミュレートする。 irb,pry等でMockを試したい時、

  • Rspec/Capybara/Turnipの入門記事を全力でまとめてみた - 酒と泪とRubyとRailsと

    Rspec/Capybara/Turnipの入門記事を全力でまとめてみた Aug 30th, 2013 Tweet さっき、『 The Rspec Book』を読み終えました。厚めのですが、RspecやCucumber、Webrat、Seleniumなどを活用するためのノウハウ満載で大満足でした! ということで、こので読んだ内容を忘れないようにするためと、その過程でRspec/Capybaraなどのネット資料をあつめたので、まとめるためにこの記事を書きます。もし、間違いを発見した場合や他にもいいリソースがあれば、是非メッセージを願いします! テスト駆動開発(TDD)と振る舞い駆動開発(BDD) テスト駆動開発(TDD)とは、コードを書く際に最初にテストを書き、次にテストが通る最低限のコードを書き、その後にリファクタリングしていく開発手法です。一方で振る舞い駆動開発(BDD)はTDDの発

  • FINDJOB!終了のお知らせ | FINDJOB!

    FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ

    FINDJOB!終了のお知らせ | FINDJOB!
  • テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー

    一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき

    テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
  • Serverspec at hbstudy #45

    PerlWindows用実行環境であるActivePerl5.28をWindows Server 2019にインストールするプロセスを説明します。インストールから動作確認までが範囲ですが、CPANなどのトピックは含みません。動画版がYoutubeにあります(OSSちゃんねる)。

    Serverspec at hbstudy #45
  • CakePHP routes.phpの確認はユニットテストで

    routes.phpを仕様に合わせて設定しておきます。 <?php // Router::connect('/:user_id/edit', array('controller' => 'user', 'action' => 'edit')); Router::connect('/', array('controller' => 'top', 'action' => 'index')); Router::connect('/:user_id/*', array('controller' => 'user', 'action' => 'index')); // Nothing Router::connect('*', array('controller' => 'nothing')); ?> 最後はシステムが取るべきURL以外ならNot Foundを出すように設定しています。これにより想定外

  • 噂のRuby&Githubなプロジェクトにスキな継続的インテグレーションサービス「Travis CI」を試してみたらすごくよかった

  • Apache Benchを使った負荷テストのやり方 | Web活メモ帳

    2016/07/11 追記しています 皆さん負荷テストツールって普段使ってますか? WEBシステムを開発する際には、1人〜十数人で開発をすると思いますが、 受諾案件では要件を満たす開発ばかりしていて速度やパフォーマンスのチューニングを行う事が少ないと思います。 いざ運用が始まって、サーバーが落ちた・・とならないように負荷テストを事前にやっておきましょう。 Apache Benchでのサーバーパフォーマンスのチェック方法をメモしておきますので、どなたかの役に立てれば幸いです。 負荷テストとは 負荷テストって何ですか?という方のために簡単に説明をすると 低い負荷ではシステム上問題が無くても、高負荷での動作だと不具合を起こす現象を回避するためのテストです。 アクセスが集中して落ちてるサイトがありますよね。。 想定されるアクセスがあっても落ちないサイトにするための負荷テストです。 Webサーバーの

    Apache Benchを使った負荷テストのやり方 | Web活メモ帳