タグ

testに関するhiromarkのブックマーク (11)

  • クロスブラウザテストの闇と闇と闇

    https://d-cube.connpass.com/event/149831/ スライド中「エンジニアの斎藤」という謎の人物が出てきますが、「エンジニアの採用」の誤記でございました。お詫び申し上げます。

    クロスブラウザテストの闇と闇と闇
  • 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と相対するドリームマッチが開催された。この会談の

    hiromark
    hiromark 2014/10/19
    悩みどころ。。。
  • テスト先に書きたい若者よ - hitode909の日記

    弊社では毎年インターンを受け入れているのだけど,いまもインターンが来てて,テスト先に書きたいけど油断すると先に実装を書いてしまう,とか話してた. 個人的には,テスト先に書くのが大事というよりかは,意識して仕様を先に考えるのが大事だと思っている.テストを先に書くと,先に仕様を考えざるを得ないので,良いスタイルが身につく. 僕がよくやるのは,関連しそうなクラスの絵をひと通りノートに書いてみて,その図だけで,うまく動くことを説明できるくらい考えてみる.その時点でおかしかったら,コード書いてもおかしくなる.ノートに方眼ついてるとクラス図書きやすい.UMLとかじゃなくても,自分で見て分かるくらいでもいいと思う. 紙でうまくいったら,外部仕様だけソースコードに書いてみる.クラス名と,メソッドの定義と,メソッドの上くらいに,ひと通りコメントでも書いてみて,この関数はこういうことをするんです,こういう引数

    テスト先に書きたい若者よ - hitode909の日記
  • エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40k

    エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
  • ssig33.com - DHH についての見解

    DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話

  • TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん

    DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco

    TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
  • 「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog

    rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動

    「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog
  • 「テストコードにはWhat,ソースコードにはHow,そして,ドキュメントにはWhyを書くんだよ!」 : ξ*゜ー゜)ξ { 遅レス。 - 日本Rubyカンファレンス 臨時打ち上げ

    もう声が出ませんでした。終新幹線をスルーしてもう一泊。 テストについて熱く テストコードにはWhat, ソースコードにはHow, そして,ドキュメントにはWhyを書くんだよ! by 角谷さん。角谷さんの LightningTalk が聞けるのは(ここ数ヶ月の間は)「- 夏イベント」だけ! 追記: 個人的には、この説明がテストコードから始まっているのもポイントだと思う。 アサマシ! APIドキュメントはテストコードにあるべきでは? by すとうさん 嫁に隠れてバカエロ 嫁のコンピューターの hosts で自サイトを適当な IP にしておく。 キーボードショートカットで別アプリで隠す準備をしつつ、対面でサーフしてるらしい ハルヒは流石に寝静まってから見てるらしい。 SeasarはJava界の救世主

    「テストコードにはWhat,ソースコードにはHow,そして,ドキュメントにはWhyを書くんだよ!」 : ξ*゜ー゜)ξ { 遅レス。 - 日本Rubyカンファレンス 臨時打ち上げ
  • ウノウラボ Unoh Labs: テスターを雇わない経営者の誤った理屈 best5

    こんにちは! やまもと@テスト番長です。 みなさんはJoel on Softwareという(とWEBサイト)をご存知でしょうか。 以前ウノウラボでもnaoyaさんがThe Joel testのエントリを書いています。 サイトの記事をひとしきり読んだあとで、は買って積んであったのですが 先日ふと手に取りぱらぱらページをめくっていたところ、 テストについて書いた面白い章があったのでご紹介します。 ■ 第22章 テスタを雇わない(間違った)理由、ベスト5 1.バグは怠惰なプログラマから出てくる →人は誰でもうっかりミスを犯します。他人の目から見たチェックをすべきです。 2.私のソフトウェアはWeb上にある。バグはすぐに直せる →リリース後の修正はずっと高くつくものです。 3.ユーザがソフトウェアをテストしてくれる →会社の品質に対する印象を悪くします。 4.テスタとして優れた資質のある

    hiromark
    hiromark 2007/02/18
    なるほど。
  • [結] 2005年8月 - 結城浩の日記 - テストが困難な性質

    目次 2005年8月31日 - Perl版の「メモ化(memoization), 再帰関数定義関数, 最小不動点」 / スマトラ沖地震・津波 / 2005年8月30日 - Windowsで、手早くPerl6で遊ぶ / 他の人から学べない「何か」 / 2005年8月29日 - ミルズの外科手術チーム / 2005年8月27日 - POPFile / 2005年8月26日 - 今日も仕事 / 2005年8月25日 - 今日も仕事 / 2005年8月24日 - 今日も仕事 / 人月はなぜ神話か / 2005年8月23日 - 説明文を書く2つのフェーズ / 秋は勉強の季節 / 2005年8月22日 - 仕事 / プログラマのダイエット / 2005年8月21日 - ジェネリクス・クイズ(2) / 2005年8月19日 - ジェネリクス・クイズ(1) / テストが困難な性質 / 2005年8月18日

    hiromark
    hiromark 2005/08/18
    ダイエットをロングテールになぞらえる、座布団1枚!
  • webアプリケーションテストツール seleniumがヤバすぎる

    http://selenium.thoughtworks.com/index.html JavaScriptを使い実際のブラウザを介してテストするseleniumがヤバすぎる。便利すぎ。Web案件なんつーのはほんと最終フェイズになってもMVCで云うモデルに当たる部分が「仕様変更」の一言によって変更されることも多々あって、そんなときは各種testが書き直しになったりする。んで最終で時間がない状態じゃtest書き直せる訳もなく人海戦術で無理矢理なんとか仕上げる、つーのがいまのWeb案件の大概の末路の気がするんだけどそれはおいといて。 このseleniumを使えば、簡単な記述で人間が実際にブラウザを操作してテストしている部分の大半である画面遷移、フォームの入力、ヴァリデーションの正否がなどが行える。つまりインターフェイスの仕様が変わらなければ延々とテストし続けられるわけだ。最後の受け入れテストの

    webアプリケーションテストツール seleniumがヤバすぎる
    hiromark
    hiromark 2005/05/25
    Javascript を使って実際のブラウザを介してテストするツール。試しに使ってみようかなぁ。
  • 1