Qiita × Uzabase Tech Meetup#1 技術講演②「TDD実践を経て変わったこと」 で発表した内容になります。 https://connpass.com/event/210103/
和田卓人さんによるテスト駆動開発問題解説の寄稿です! バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中! by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね! で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
CloudBees BlogExploring the frontiers of product delivery and technology Mastering Pipeline Management - Making Complex Workflows Transparent with Pipeline Explorer Achieve seamless DevOps pipeline management with Pipeline Explorer! Streamline troubleshooting, enhance visibility, and boost collaboration in DevOps. →
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか? グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
Webサイトを構築する際に、どのバージョンのブラウザまでサポートするかが問題になりやすい。最新のバージョンだけであれば良いのだが、不特定多数へのサービス提供となればそうもいかないだろう。 様々なバージョンのIEが立ち上げられる IEの場合で言えば5.5以降を対象とする場合が多いように思う。だがそんなバージョンのIEを簡単に用意できるだろうか。そこで使いたいのがこのソフトウェアだ。 今回紹介するフリーウェアはInternet Explorer Collection、様々なバージョンを収録したIEだ。 Internet Explorer Collectionで提供されるバージョンは1.0/1.5/2.01/3.0/4.01/5.01/5.5/6.0/7.0/8.0となっている。8.0β版まで収録されているので、今後を見越した上でのテストが実行できるようになる。 なぜかインストーラーはVista
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く