正しい日付を入力してるのにエラーになるときがある - CAT GETTING OUT OF A BAG
今年に入ってから二つの異なるソフトウェア（iOSアプリと組み込み系）で「正しい日付を入力してるのにエラーになるときがある」というバグに遭遇しました。おかしさっぷりが似ていて、きっとこれは「よくある不具合」なんだろうなと思いました。 軽い気持ちでお題風にツイートした 日付欄の入力チェック処理で「正しい日付を入力してるのにエラーになるときがある」というバグが潜んでいるとしたら 1. どのようなことが起きていると思いますか？ 2. (ソースコードは見れないとして)どんなテストをしてみますか？— miwa (@miwa719) 2021年9月7日 軽い気持ちでお題風にツイートしたら「ソフトウェア開発で日付を扱うときに気にしたほうがいいこと」が、たくさん集まりました。うれしかったです。 「1. どのようなことが起きていると思いますか？」では、失敗しそうなシチュエーションや疑わしいところ、確認したい事
PageObjectデザインパターンを利用して画面変更に強いUIテストを作成する│ソフトウェアテストラボ｜アプリテスト｜スマートフォンテスト｜株式会社SHIFT
今回は、Selenium2（WebDriver）でテストケースを作成するときに知っていると便利な「PageObjectデザインパターン」をご紹介します。 こんな方におすすめ SeleniumはWebブラウザ上で動作するアプリケーションの自動テストツールの中では圧倒的な知名度のあるツールです。2011年にSelenium2がリリースされてからは大きくアーキテクチャが変わり使い勝手も向上しましたが、実際に大量のテストケースを作成・保守するとなると書き方に工夫をする必要があります。 PageObjectデザインパターンの考え方は、 ・WebDriverでテストを自動化しているけど、画面変更にテストケースの修正が追いつかず困っている ・WebDriverでテストを自動化したいけど、どのようにテストケースを作成すれば良いのかわからない という方々にとってとても参考になります。 PageObjectと
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
Working Effectively with Unit Tests
tl;dr: This book details my strong opinions on the best way to test, while acknowledging alternative styles and various contexts in which tests are written. Whether you prefer my style or not, this book will help you write better Unit Tests. From the Preface: Over a dozen years ago I read Refactoring for the first time; it immediately became my bible. While Refactoring isn’t about testing, it expl
ssig33.com - DHH についての見解
DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の本質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話
TDD is dead. Long live testing. (DHH)
By David Heinemeier Hansson on April 23, 2014 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 discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
テスト駆動型開発についての議論 - ワザノバ | wazanova
http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約7時間前 Test Double社がブログで、TDD (テスト駆動型開発) を教える場合のアプローチを提案しています。 TDDについて、同じ用語やツールを使っていても、「モックオブジェクトがありすぎて、ひどい。」「モックオブジェクトがあふれていて素晴らしい!」という異なる見解に至るケースがでてしまっているのは、理想的なゴールに至る道筋を統一したかたちで教えきれてないからだと指摘しています。 TDDの一番の効果はコードのデザインの改善であり、コードのクオリティの担保は、うまくいけば二次的な効果、まかり間違えば幻想
The Art of Unit Testing, Second Edition
Functional Design and Architecture—Save 45% TODAY ONLY!
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 プロダクションコードのように
どうしてもprivateメンバをテストしたい人に対する、JUnit4での解決案 - kencobaの日記
そもそもJUnitは、振る舞いのテスト(≒ブラックボックステスト)を前提としている(こんなデータを入れたら、こんな結果が返りますよーという意味で)。 privateメンバをテストしたいというのは、ホワイトボックステストをしたいということである(このメソッドは内部で別のメンバを使ってますよーという意味で)。 実際のところ、JUnitでは、privateメンバのテスト手段は提供されていない。 何とかしてprivateメンバをテストしたい、ということで、リフレクションを利用する人がいる。だが、リフレクションを利用するとリファクタリングが難しくなる(フィールド名を文字列で指定することになるため)。テストコードの書き方のせいで、リファクタリング作業が阻害されるのでは、本末転倒である。 そこで、どうしてもprivateメンバをテストしないと気が済まない人のため、別の解決案を考えた。 import ja
UnitTestのためのクラス設計
Editor's Notes\n\n\n\n\nユニットテストの説明に前に本講義で多用されるオブジェクト指向と&
TDDカンファレンスでLTしてきたのでその補足
4月の6日のTDDカンファレンスに参加<発表してきた。参加といっても遅刻していったのでほとんど話を聞けていないのだけれど。 とりあえず資料はこちら。読み直してみたら途中の話の飛躍がこれはひどい。当日もかなり短い発表の上に色々内容を省いてしまったので色々と補足しておく。(当日聞いていただいた方に申し訳ないし、あまりこういうのはよくないね。パブリックスピーカー読んででなおします。) 今回の内容の発端は「TDDはテストではない」という言葉の暴力性というか、言い切りに何となく違和感を感じていたのがきっかけ。もちろん、誤解されたくないという意味では言い切るのは大事なんだろうけどちょっとだけ暴力的に感じる。暴力的に感じる理由は資料にも書いてあるけど、実際TDDで書いたユニットテストはテスト資産として流用している。それは副産物的なものかもしれないけれど、TDDの効果としては大きいんだから言い切っちゃ
かっこ悪くて面倒でもテストコードを書こう - 今川館
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ez-design.net
このページを見るには、ログインまたは登録してください
yokohama.devtesting #2
Facebook
モダンPerlリファクタリング #yapcasia
はてなブログ | 無料ブログを作成しよう