非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
CircleCI導入したのでwerckerとの比較も含めてまとめ - 月曜日までに考えておきます
最近話題のCI as a Serviceを導入すべく調査してみました。JenkinsさんもすごくいいのですがAWS smallインスタンスに乗せているとやっぱり本来の力を発揮できない感じがあるので。 CircleCIって以前は、一番安い契約だと1Private Repositoryしか扱えなくて使いづらそうな印象だったのですが、4月末頃にPrivate Repository数は無制限、同時実行ジョブ数で課金というPlanに変更になったようですね。 Simple and Transparent Pricing | The Circle Blog http://blog.circleci.com/simple-and-transparent-pricing/ 自分の関わっているプロジェクトでは、 リポジトリはそれぞれの役割ごとにいくつか分けている 開発者数は少ないのでコミット頻度はそんなに高く
「メソッドに対してテストをするな」という話題について - その手の平は尻もつかめるさ
―「間違っているかもしれないので，その時はこの銃で僕を撃ってくれ，良いね？」 [2014-05-19T17:48:28Z 追記] http://a-suenami.hatenablog.com/entry/2014/05/17/131326 補足してもらったので読むと良いと思います． わかっちゃはいたけれど上手く言語化できていなかった部分，あるいはわかっていない部分について言及されていたので参考になりました．ありがとうございます． いやーつーかさー，「『メソッドに対するテスト』っていう言葉自体がわかりにくくね？」っていうのはその文言を見たり，この文章書いている間もずっと思ってて，つまり端的に言うとそういう事を言いたかったはずなのに，今このエントリ読み返すとそうした[趣主]旨から完全にズレててメッチャ違和感あるな！ ってなりました．俺のバカ！ これを仮に言い換えるとしたら「内部構造に対するテ
テスト駆動開発／振る舞い駆動開発を始めるための基礎知識
連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」（Test Driven Development、以下「TDD」）は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。 本稿では、そうしたTDDの発展や、振る舞い駆動開発（Behavior Driven Development、以下「BDD」）など他のテストファースト手法への展開についても解説します。 ※編集部注：ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J
テスト駆動開発のテストは、テストか？―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]
アジャイル開発の中の１つのプラクティスであるTDD(Test Driven Development、テスト駆動開発)に使われるユニット・テスト、というものの役割について、よくテスト界の人との意見の相違がある。テストとしての完全性、や、品質保証についての考え方から見ると、テストとは呼べないのでは？ということ。 最近、アメリカテスト界の有名人であり、アジャイルコミュニティへの貢献も大きい、Brain Marick(www.testing.com/cgi-bin/blog) 氏とメールで話す機会があった。 アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ これは、以前「テストの役割=進捗管理＋設計戦略」 blogs.itmedia.co.jp/hiranabe/2005/08/sd4__c05e.html で 紹介した、t-wadaさんの「テス
![テスト駆動開発のテストは、テストか？―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/940258f08a8861f663a305f5e532f8d8c90667bb/height=288;version=1;width=512/https%3A%2F%2Fblogs.itmedia.co.jp%2Fmt-static%2Fsupport%2Fassets_c%2Fuserpics%2Fuserpic-20-100x100.png)
テストを書く文化を育てる戦略と戦術
at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464Read less
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
テストをすっきり書く方法 - 2012-04-25 - ククログ
はじめに ソフトウェアを作るときには同時にテストも作ります。 テストを動かすことで、ソフトウェアが設計の通り動作しているかを確認できます。もし設計の通りに動作しない場合はテストが失敗し、ソフトウェアに期待する動作と現在の間違った動作が明確になります。 テストをすっきりと書くことができると、テストを読みやすくなり、また、きれいなソースコードのままで新しくテストを追加することができます。 今回は、そのすっきりとテストを書くための方法について説明します。 テストを追加していくと発生する問題 例えば、1つのテストケースの中にいろいろな機能のテストがある場合を考えます。 ここで、ある機能の実装を修正したので、この機能に関するテストを追加しようとしました。 テスト名に「テストのコンテキスト」と「テスト対象」を含めてどのような内容のテストかを示します。 このとき、ある機能に対して様々な動作をテストするこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: TDDを根づかせる:導入の問題と解決策
Bitbucket | Git solution for teams using Jira
GitHub - rspec/rspec-expectations: Provides a readable API to express expected outcomes of a code example