テスト駆動開発から始めるRuby入門 ~2時間でTDDとリファクタリングのエッセンスを体験する~ - Qiita
エピソード1 初めに この記事は一応、Ruby入門者向けの記事ですが同時にテスト駆動開発入門者向けともなっています。 対象レベルによって以下のように読み進められれば効率が良いかと思います。 Ruby入門者でプログラミング初心者・・・とりあえずコードの部分だけを写経しましょう。解説文は最初のうちは何言ってるかわからないと思うので5回ぐらい写経してRubyを書く感覚がつかめてきてから読み直すといいでしょう。もっと知りたくなったら参考図書にあたってください。と言っても結構お高いので「リーダブルコード」と「かんたんRuby（プログラミングの教科書）」といった初心者向け言語入門書から買い揃えるのがおすすめです。 Ruby経験者でテスト駆動開発初心者・・・コード部分を写経しながら解説文を読み進めていきましょう。短いステップでテスト駆動のリズムが感覚がイメージしていただければ幸いです。もっと知りたくなっ
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
テスト駆動開発から証明駆動開発へ #JTF2019 / July Tech Festa 2019
July Tech Festa 2019 で使用したスライドです。 近年、テストを書く文化は広く普及しており、開発フローにおいて自動テストを組み込むことはもはや常識となりました。しかしよく考えてみると、有限個のテストケースが保証しているのは、所詮「特定の有限個の入力に対する出力」にしか過ぎません。では「あり得る全ての入力」に対してプログラムの性質を保証することは果たして可能でしょうか？ この問いに対する答えのひとつが「定理証明」と呼ばれる手法です。定理証明では、数学的な「証明」をプログラム上でエンコードすることにより、真に「全ての入力」を扱うことができます。本セッションではこの定理証明を取り上げ、従来のテストとの考え方の違いや具体的な適用方法について、サンプルを交えつつ解説します。 イベント概要：https://2019.techfesta.jp/speakers#A10
Unityでテストコードを書いて会得した最強のTips(苦肉の策ともいう) - Qiita
最強のTips(苦肉の策)が生まれるきっかけ 自分が現在開発に携わっているゲームでは、作中に多くのシナリオが含まれています。 その数はデータにして200を超えていますが、このデータが増えるにつれて、ある問題が発生しました。 それは、シナリオデータの数が多すぎて、不具合のあるデータがあることに気付けないということです。 （特定の選択肢を選ぶと、進行不能になるデータがいくつか見られました） これに対処するため、「全シナリオの動作チェックを行うUIのテストコードを書こう！」と思ったのが、事の始まりです。 まさか、あんな苦肉の策を取ることになるとは、この時は考えてもいませんでした… 目次（Tips一覧） 自分がテストコードを書いて会得したTipsを紹介します。 ちなみに、最強のTips(苦肉の策)は「6. テストの失敗が後続のテストにまで影響を与えないようにする」です。 それ以外は、まとも（のはず
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
【社内勉強会】和田卓人氏によるレガシーコード改善ワークショップを開催しました
サーバーサイドエンジニアサブマネージャーの崔です。 少し前のことになりますが、テスト駆動開発（TDD）のエバンジェリストである和田卓人（@t-wada）さんを講師としてお招きし、1日かけてレガシーコード改善ワークショップを開催しました。 和田さんには以前にも、社内でテスト文化への理解を広めたいという意図もあり講演をお願いし、非常に好評だったため、今回はより実践的なワークショップを開催することにしました。 私たちが長期にわたって運用を続けるゲームタイトルは、機能追加や改善を繰り返し、システムが大規模かつ複雑になってしまいます。開発のスピードとプログラム品質の両立に影響するため、これらを改善する取り組みのひとつとして、テストを活用して開発効率を上げたいと考えました。 そして、今回はより実践的なワークショップにするために、Cygamesで実際に運用しているゲームタイトルのソースコードを利用しまし
「FF6」の新たなバグを発売25年後に見つけたテスト技術者の腕前
1994年に発売された大人気ゲーム「ファイナルファンタジーVI（FF6）」（スーパーファミコン版）をやりこみ、2019年になっても未発見の「バグ」を見つけ出し続けている人がいる。ここ数年、熱心なゲームファンを何度も驚かせているのが、「エディ」のハンドルネームで知られるプレーヤーだ。必須のイベントをクリアせずに先に進める方法を見つけ出し、毎年のようにゲームクリアまでの「歩数」の最少記録を更新している。 本記事でいうバグとは、ゲーム開発者が意図していなかったと推測される仕様を含む。特別な操作をすると通常とは異なる挙動となり、いわゆる「裏技」が可能になる。 FF6スーパーファミコン版はスクウェア（現スクウェア・エニックス）が開発したロールプレイングゲーム（RPG）で、美しいグラフィック、ドラマチックなシナリオ、完成度の高いゲームシステムが好評を博し、全世界で約340万本の売り上げを記録した。人気
モッククラスを使うべきか否か - 日々常々
元ネタ: モッククラス、下から見るか？横から見るか？ モッククラスを使うべきか否か、というネタを拾ったので書いてみます。これまでにモックについて殆ど書いてないことに気づいて驚きつつ。 Short Answer 「モックに何をさせたいの？」 質問に質問で返すなという感じですが、モックに何をさせたいか答えてみれば、モックを使うべきか否かはだいたい決まるよなーと思うのです。 モックは道具で、使うことで何かを改善するものです。 「このことをテストしたいから、モックをこう使う。」という文脈なく使用すると、無用な複雑性を作り込むことになります。 モックの使用は負債なので、十二分に利益を見込める場合にのみ使用するものだと思っています。 これはモックに限った話ではなく、何かを便利にするために道具を追加する際は必ず付いて回るトレードオフです。 Short Answer 露払い 使うべきか否か どちらでも差が
iOSアプリ開発自動テストの教科書 〜XCTestによる単体テスト・UIテストから，CI/CD，デバッグ技術まで
書籍案内 » 書籍ジャンル » プログラミング・システム開発 » iOS・Androidなど » iOSアプリ開発自動テストの教科書 〜XCTestによる単体テスト・UIテストから、CI/CD、デバッグ技術まで この本の概要 「iPhone X，XR，iPad……端末が多すぎて，テストが手動じゃ追いつかない」 「競争が激しいアプリ開発現場で，スピードを落とさずテストしなければ」 「どうして，テストしたはずのアプリで，ユーザーからこんなにバグが報告されるんだ」 競争が激化し，複雑になるiOSアプリの開発において，こんな問題を解決できる手段が「自動テスト」です。 本書は，DeNAの開発生産性や品質を担うSWETグループのエンジニアたちが，iOSアプリ開発の自動テストにフォーカスしてまとめた，これまでにない“テストの入門書”です。自動テストの基本はもちろん，単体テスト・UIテスト，CI/CD，さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドテスト入門
明日からはじめるテストのあるフロントエンド開発 ~ テスティングトロフィー ~
About UITests
20年後のソフトウェアテストの話をしよう / Software Testing for 20 years later
GitHub - goldbergyoni/javascript-testing-best-practices: 📗🌐 🚢 Comprehensive and exhaustive JavaScript & Node.js testing best practices (July 2023)
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01
GitPitch Markdown
Web-E2E-Testing-from-Ruby
負荷試験コトハジメ
GitHub - typelift/SwiftCheck: QuickCheck for Swift
