きょん@アジャイルコーチ、システムアーキテクト @kyon_mm 僕が不勉強な部分はあるのだけど、「静的型付け関数型プログラミングだとOOよりもTDD(BDD)がしやすい(もしくはいらない)」とかたまにいう人がいるんだけど、その人がまともにTDD/BDDの説明しているの聞いたことがないので、まるで参考にならない意見ばかりでつらいです。 2014-04-17 12:49:49
![「静的型付け関数型プログラミングだとOOよりもTDD(BDD)がしやすい(もしくはいらない)」?](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f4f104bcc0937c808a9f3aa01a62e1bdf4cfea3/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F55e3e6e818368ec68c7e416f48935c4d-1200x630.png)
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm 僕が不勉強な部分はあるのだけど、「静的型付け関数型プログラミングだとOOよりもTDD(BDD)がしやすい(もしくはいらない)」とかたまにいう人がいるんだけど、その人がまともにTDD/BDDの説明しているの聞いたことがないので、まるで参考にならない意見ばかりでつらいです。 2014-04-17 12:49:49
kitchen-dockerでEC2の料金をかけず、高速にAmazon LinuxでのCookbookのテストを行う方法 2014.04.28 追記: ライセンスについてのご質問をいただいたので追記しました。 最近、Kitchen-dockerでCookbookのテストを流すようになり、 捗ってはいたのですが、 仕事ではCentOSとAmazon Linuxの両方を使うことがあり、 お互いRHEL互換で大体同じで通るとはいえ、 ちゃんと両方でテストしないといけないよな〜と思っていました。 でも、Amazon Linuxを使おうと思うと、 kitchen-ec2とかvagrant-awsとかで立ち上げる感じになって、 やっぱり仮想マシンの立ち上げが遅いんですよね。 あと、課金を気にしなきゃいけないのが一番やりにくい。 とりあえず、今やってるCookbookの充実&リファクタリングは早く終わら
昨日は 葉桜js でした。 今回は客層からかテストとセキュリティの話が多かった。t_wada, malaさんの影響は大きい。 #葉桜JS— Yosuke FURUKAWA (@yosuke_furukawa) April 14, 2014 僕のLT t_wadaさんが来るということでテストっぽい話をしたくて、Docker Node Testerの話をしました。 Node.js v0.12 に関して このブログで Node.js v0.12で変わることについて色々と紹介してきました。NANの話もそうですし、traicing apiとかsync child_processもそうです。 Node.js v0.12では他にもコアモジュールに色々とバグ修正やエンハンスが加わっています。 コアチームが互換性に配慮しているとはいえ、影響を受けてしまい、自分のモジュールが動かなくなることは考えられます。
Your typical test code Here’s some typical test code found in many codebases @Test public void testCalculateTaxRate() { TaxRateCalculator calculator = new TaxRateCalculator(); Int value = calculator.calculateRate(200, 10); assertEquals(300,value); } This code suffers from several issues. Under what conditions is the tax rate calculated? What exactly is it doing? What is the expected outcome? Being
最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が
serverspecとdocker-apiでDockerfileをTDD いくつかDockerfileを書いてきた.今書いているDockerfileは短くてシンプルなものばかりだが,もっと長く複雑化した時に不安になりそうだ.不安を解消するにはテストしかない.さらにテスト駆動的にDockerイメージを開発できたら素敵だ.つまり, テストを書く Dockerイメージを作成して,テストの実行 -> RED Dockerfileの編集 Dockerイメージを作成して,テストの実行 -> GREEN テストを… の流れができるとよい. ということで,RSpecを使ってTDDでDockerfileを開発するというのをやってみた,tcnksm/docker-rspec.今回実現したのは以下. Docker Remote APIでDockerfile特有のコマンド(e.g, CMDやEXPOSE)のRSp
iOSのアプリケーションではモデル周りのテストと同じぐらいUI周りのテストが重要な気がするのですが、画面のテストってちょっと面倒ですよね。その上Xcode標準のテストフレームワークでは画面遷移などのテストができません。そこで、統合テスト用のテストフレームワークを使う必要がでてきます。 選択肢はいくつかありますが、使い方がシンプルで導入も容易なKIF Frameworkを紹介します。 KIF Framework GitHub - kif-framework/KIF: Keep It Functional - An iOS Functional Testing Framework KIFは決済サービスSquareが自社アプリケーションの統合テストのために開発したフレームワークだそうです。KIFを使ったテストではボタンをタップして画面遷移したり、画面遷移した先のUIの存在を確認したりといったこと
最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く