タグ

tddに関するgriefworkerのブックマーク (8)

  • 実録レガシーコード改善 / Working with Legacy Code: the True Record

    2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエピソードとコードをプロダクトオーナー(引き継ぎ前のコードを書いた人)の許可を得て使用しています。登場するコードは全て物、登場するデータは講演用の架空のものです。

    実録レガシーコード改善 / Working with Legacy Code: the True Record
  • 現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ

    この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです(これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE)。旧記事には当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出

    現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
  • テスト先に書きたい若者よ - hitode909の日記

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

    テスト先に書きたい若者よ - hitode909の日記
  • TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん


    DHH"TDD is dead. Long live testing."   By David Heinemeier Hansson on April 23, 2014  David Heinemeier Hansson 2014423 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming.  Itdidn't start out like that. When I first disco
    TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
    griefworker
    griefworker 2014/04/24
    “テスティングよ栄えよ”
  • 久々にチーム開発したのでメモ - ひげろぐ


    Rails 3 使   Web /   Github  Pull Request   Github使Git  
  • テストファーストなGitワークフローについて - kazuhoのメモ置き場


    Git使 GitHubGitHub Enterprise使master 2 origin master origin master1st parentcommit  master(12:44)git bisect
    テストファーストなGitワークフローについて - kazuhoのメモ置き場
  • 不具合にテストを書いて立ち向かう - t-wadaのブログ

    テストを行っている品質保証チームや、実際にシステムを使っているお客様から不具合が報告されたとき、あなたはどう思いますか? 悲しんだり、恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、一つの不具合修正が三つの新たな不具合を生んでしまうようなことになりがちです。 テスト駆動開発(TDD : Test Driven Development)は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか? やはりテストを書いて立ち向かってゆくのです。私はテスト駆動開発を数年間実践してきた中で、心がけているひとつの「掟」があります。それは「不具合の修正時

    不具合にテストを書いて立ち向かう - t-wadaのブログ
  • Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記

    テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ

    Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
    griefworker
    griefworker 2013/11/28
    テストは自分が楽をするためというのもあるけど、安心するためにも書いてる。
  • 1