[B! tdd] hiroki23のブックマーク

TDD実践を経て変わったこと

Qiita × Uzabase Tech Meetup#1 技術講演②「TDD実践を経て変わったこと」で発表した内容になります。 https://connpass.com/event/210103/

hiroki23 2021/04/28

リンク

python-tdd

みんなのPython勉強会#37 の資料 https://startpython.connpass.com/event/81625/presentation/

hiroki23 2018/09/19

python
tdd

リンク

組織にテストを書く文化を根付かせる戦略と戦術 / Strategy and Tactics of Building Automated Testing Culture into Organization

2017/12/19 Tech Night @ Shiodome # 6 https://techsio.connpass.com/event/72585/

hiroki23 2018/08/29

リンク

これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE

和田卓人さんによるテスト駆動開発問題解説の寄稿です！バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局はじめにこんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。問題文私が出した問題は、以下のようなものでした。問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。【仕様1】「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上

hiroki23 2016/01/22

test
tdd

リンク

テストについての個人の雑感 - tokuhirom's blog

テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。ざっくりいうと「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」テストに対する認識ソフトウェアにたいするテストというものはソフトウェアそのものの価値には関係しない。なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについてオープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ

hiroki23 2014/01/22

リンク

アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io

Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系のQAエンジニアなので現場感覚はそれなりにあるつもりです。で、早速なんだけど上記ブログから引用させてもらうとまぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば﹁ままごと﹂みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんとQAやった人間からすると境界値テストすらしてないしホワイトボックステストだ

hiroki23 2014/01/17

リンク

テストのめどい話

最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が

hiroki23 2014/01/14

リンク

テスト考2014 - Hidden in Plain Sight

年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。期待するも

hiroki23 2014/01/14

リンク

軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ

これは、TDD Advent Calendar jp:2012 の16日目のエントリーです。前日のエントリーは、@pocketberserkerさんの「Specs2のParameterized Testのはなし」でした。ご存じの方も多くなっていると思いますが、「テスト駆動開発（以下、TDD）」とはテストコードを先に書くテストファーストを基盤とした開発手法です。先にテストコードを書く事により、これからどのようなプロダクションコードを書こうとしているかを明確にすることができることが特徴です。このため、テストの技法というようりは設計の技法です。テスト駆動開発を実践することにより多くのメリットを得ることができます。このことは2011年のAdvent Calendarで言及しました（TDDを学ぶべき10の理由 #TddAdventJp）。TDDは簡単に導入することができる一方で、実践するのは非常

hiroki23 2012/12/20

リンク

CloudBees Blog

Discover the advantages the pipeline visualization tool provides to Jenkins and CloudBees CI users by making complex tasks more manageable. →

hiroki23 2012/12/01

git

リンク

RSpec の入門とその一歩先へ - t-wada の日記（旧）

和田卓人(@t_wada) 作﹃RSpec の入門とその一歩先へ﹄はクリエイティブ・コモンズ表示 - 継承 4.0 国際ライセンスで提供されています。東京 Ruby 会議03の RSpec ワークショップの資料です。このワークショップでは参加者の方に﹁写経﹂(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter のみたいなNGワードのフィルタリング機能を RSpec で作りましょう。まずはNGワードの検出機能を作成します。このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま

hiroki23 2012/09/04

リンク

みゆっき☆Think 第10回「チーム開発～脱ぼっちマインド～」 - ドワンゴ研究開発ブログ

こんにちは。ドワンゴの荒木です。弊社若手エンジニア鳥居みゆっきと一緒に技術を学ぶ生放送﹁みゆっき☆Think﹂！第10回のテーマは﹁チーム開発～脱ぼっちマインド～﹂放送内で使用されたスライドと、みゆっきノートを公開します。放送内で使用された資料はこちら↓ みゆっき☆Think#10 チーム開発〜脱ぼっちマインド〜 View more presentations from akitsukada みゆっきノートは、みゆっきが期末テスト中のためアップロードを延期しています。しばらくお待ち下さい。 > 放送を見逃された方は、チャンネルのアーカイブ動画で視聴いただけますので、是非ご覧下さい！第11回みゆっき☆Thinkは年始のお休みの都合により、1/13︵金︶夜7時からの放送を予定しております。是非、次回もご覧下さい！

hiroki23 2011/12/20

コメントはwhyを書くなど

リンク

アジャイルにTDDしようとしてペアプロして失敗した話 - 水まんじゅう2

これはTDD Advent Calendarの18日目。記事としては @mao_instantlife さんの TDDやってみてコメントが減った話のあと、@cubeon さんのきっと方眼の理から逃れられないお前たちにも告げる！テストコードを手に入れるのだ！の前となります。最近、新しい開発手法の一貫としてTDDを採用しようとするプロジェクトが出始めている印象があります。ただし、とりあえず取り入れてみたけれどもうまくいかなくて結局ウォーターフォール方式に逆戻りという例も多いのではないでしょうか。以前、アジャイルにTDDをしようとしてペアプロして失敗したプロジェクトの話を聞いたことがあるので書こうと思います。その時のプロジェクトでは数百人月前後の工数をかけてそれまであったレガシーシステムをJavaでリプレイスしようとしていたようです。それなりの規模のプロジェクトに多いように、さ