テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
PoohSunny's blog
はじめに これは「子育てエンジニアAdvent Calendar 2023」 9日目の記事です。 adventar.org 引き継ぎの苦痛を考える 育児する上で、夫婦で協力する場面は多いと思います。今回はそんな中で自分的に難しいと思っている引き継ぎの苦痛について話します。 コンテキスト 私の持ってたコンテキストはここに記載があります。 speakerdeck.com ざっくりと - 子ども二人、愛犬が3匹 - 妻の１年のアメリカ出張に伴い、その間の家事、育児を担当 - 家事スキルがアップしたことにより、妻の出張後も基本的に家事を担当 です。 チームワークが活かしきれない 一人で家事をしていたところから、二人になって本来的にはパワーアップしているはずなのに、なかなか活かせずにいました。 その原因は引き継ぎに伴う苦痛です。 例えば下記の状況を考えます。 疲れたり酔っ払ったりして、洗い物をできず
プログラムを書く順番とテスト駆動開発について - Line 1: Error: Invalid Blog('by Esehara' )
下の本を読んでいた。 プログラミングの基礎 (Computer Science Library) 作者: 浅井健一出版社/メーカー: サイエンス社発売日: 2007/03メディア: 単行本購入: 17人 クリック: 409回この商品を含むブログ (105件) を見る この本はどういう本かといえば、OCamlという、関数型言語と呼ばれる中でも、あまり有名ではないほうの言語（というと失礼だけど）を使ってプログラミングの基礎を学ぶという本。そういうと、OCaml好きな人には怒られるかもしれないけれども。 良いにしろ、悪いにしろ、関数型言語の特徴は、個々のパーツを作って云々という部分が非常にクリアーになっているところであるな、とは思う。というのも、下手に「代入」を使わないことによって、むしろデータ操作の流れがクリアになるし、余りに大きいパーツにしてしまうと、そもそもその流れ自体がよくわからなくなる
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
jstest
The cross-platform JavaScript test framework jstest is a testing framework for JavaScript that’s designed to run on any platform with minimal effort. It provides a familiar RSpec-style API for organising tests that can run on the following platforms: Web browsers: Chrome, Firefox, Internet Explorer, Opera, Safari Headless browsers: PhantomJS, SlimerJS Server-side platforms: Node.js, Narwhal, Ringo
テスト駆動開発の効果はどのくらいある？
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
oreilly.com
Build the skills your teams need Give your teams the O’Reilly learning platform and equip them with the resources that drive business outcomes. Click on a feature below to explore. Trusted content Live online events Courses Interactive learning Certification prep O’Reilly Answers AI Academy Assignments Insights Dashboard Trusted content you can count on More than 60K titles from O’Reilly and nearl
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0064 号 バックナンバー Rubyist Magazine 0064 号 Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist
テスト駆動開発による組み込みプログラミングも良い本です - プログラマの思索
「テスト駆動開発による組み込みプログラミング」を頂きました。 ありがとうございます。 既に色んな方が感想を書かれています。 【元ネタ】 「テスト駆動開発による組み込みプログラミング」 - Yasuo's Notebook [書評]テスト駆動開発による組み込みプログラミング | Ryuzee.com O'Reilly Japan - テスト駆動開発による組み込みプログラミング 書籍『テスト駆動開発による組み込みプログラミング』：柴田 芳樹 (Yoshiki Shibata)：So-netブログ "これこそ私の探していたものだった" - テスト駆動開発による組み込みプログラミング: 菊と書評 テスト駆動開発は設計技法である～組み込みアジャイルコーチ James Grenning さんインタビュー: プログラマの思索 C言語でTDDをやる場合、JavaやRubyに比べると、リフレクションやモック
[lib] モックとスタブの違い
TEST http://d.hatena.ne.jp/devbankh/201001 モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002 モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124 簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次
「CIを半年間まわしてみて」というお題でLTをしてきました - kaz29
大分時間も経ってしまい今更ではありますが、先日行われた第67回 PHP勉強会で「CIを半年間まわしてみて」というお題でLTをしてきました。 昨年の11/30に、当時ちょうど開発が始まった案件の開発環境に関して「今時なCakePHPでの開発環境！？」というエントリーを書いて、初のホッテントリ入りしました。4月末でこのプトジェクトが始まって半年という事で、実際にCIをまわしている中で起こった事や、試行錯誤しつつどうやって解決したかなどを簡単にまとめてお話ししました。 LT用に作った資料ではちょっと伝わりにくいので、以下にまとめ直しました。 成長の軌跡 Jenkinsサーバーを立ち上げた時は、UnitTestのテストケースが10個だけだったのですが、4/30現在 UnitTestのテストケースが467件、受入れテストのシナリオ数が292件とものすごい成長っぷりです。 この半年間に起こった事 テス
単体テストガイドライン — The Pylons Project Documentation (翻訳)
単体テストガイドライン¶ Pylons プロジェクトは、このドキュメントの元となった Tres Seaver によって書かれた Avoiding Temptation: Notes on using unittest effectively に倣ったユニットテスト教義をかなり厳格に守っています。 Note このドキュメントは、ほとんど排他的に 単体 テストを扱います。 結合テストまたは機能テストに対しては私たちは特別の教義を持っていません。 しかし、下記の tips の多くはその文脈でも再利用できます。 悪い単体テストを避けるための tips¶ ある人々は “don’t repeat yourself” をむやみに信じてきました (drink the KoolAid): 私たちは、ほとんどの場合にはコードの繰り返しをしないことが 美徳であることに同意します。しかし、単体テストコードはその例
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年間で皆さまの知識
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～ Presentation Transcript DevelopersSummit 自動改札機の 運賃計算プログラムのデバッグ手法 ～1040のパターンをいかにテストするか～14-B-3 幡山 五郎#devsumiB オムロンソーシアルソリューションズ ソリューション事業本部 Developers Summit 2013 Action ! １．自動改札機について 1. 自動改札機について 2. 間違えない自動改札機 2 １．自動改札機について自動改札機導入前の改札風景 3 １．自動改札機について磁気からＩＣへ求められる技術が変わってきた（高機能化→高信頼化） 2013年 ＩＣ乗車券全国共通化（北海道～九州の10種類） 2007年 ＰＡＳＭＯ導入、Suica+PASMO
ユニットテスト、ここどうするの？
こんにちは、斉藤です。 前々回はTDDというユニットテストを使った開発方法、前回はユニットテスト実行の自動化と、触れてきました。 今回もやっぱりユニットテストについてということで、方法論などをtips形式でお送りします。 * プライベートメソッドのテスト ユニットテストでは、公開されているメソッドを呼び出して実行します。 クラスを書いたことがある方なら知っている通り、プライベートメソッドを外部から呼び出すことは出来ません。 そのため一般的にこれは、避けた方が良いと言われていますが・・・自分はテストしたい派なので、以下の方法をご紹介します。 - パブリックメソッドでプライベートメソッドを呼び出す 一番簡単な方法ですね。 ただしこの場合だと、公開APIと非公開APIの区別が出来なくなってしまいます。 クラスに手を入れることになり、テストのためだけのコードが混じってしまうことがデメリットです。
規模別PHPUnitでのテストの書き方いろいろ - Architect Note
最近になってPHPUnitをちゃんと使ってユニットテストを書くようになってきたのですが、まだまだTipsが足りないと感じます。個人的に実践している書き方をいくつか並べてみます。 追記：最初、シェバングと書いていましたが、オプションを渡せる数が決まっていたりOSによっては動かなかったりとあまり便利でないことがわかりました。。phpunit.xmlを書いた方がいいかも。 ちょっとしたテスト → シェルスクリプト化する PHPUnitは高機能なのですが、いかんせん最初の障壁が高いと思います。とにかく気軽に書きたいなら、シェルスクリプトを作って単独ファイルで実行できるようにするといいです。 #!/bin/sh phpunit --colors *Test.php # ↑オプションを書き並べておく <?php class SampleTest extends PHPUnit_Framework_Te
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD Boot Camp(TDDBC) - FrontPage
テスト駆動開発のはじめ方
【社内勉強会レポート】 TDDへの理解を深めるため、スライド資料「TDDを実践してわかった TDDつまづくあるあると自分なりの乗り越え方まとめ」を読む会を行いました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
RSpecでテストを作るのに役立つ「モック/スタブ」のシンプルな説明
