テスト駆動開発を実習形式で手を動かして体得するTDD Boot Campの社内版を実施しました - アニメイトラボ開発者ブログ
古きよき時代から来ました、まじめなSE、まじめにSE。 id:bash0C7 です。 先日、テスト駆動開発を座学だけでなく実習形式で手を動かして身につけるイベント、TDD Boot Campの社内版を開催しました。 このエントリーではどういった狙いでどのようなかたちで開催したのかを解説します。 TDD Boot Campとは TDD Boot Camp(TDDBC) - TDDBC のサイトに下記の説明があります。 TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。 各地のコミュニティの方々が中心となって、全国各地で行われています。 わたしはかつて2010年の 7月10日 TDD Boot Camp名古屋(愛知県) に参加し、そのおかげできちっ
たった1人から始める社内テストコード文化
# -*- coding: utf-8 -*- from __future__ import absolute_import, unicode_literals # テストする関数 def add(a, b): return a + b # テストコード 関数名はtest_ から始めるのがpytestでのお作法 def test_add(): assert add(1, 1) == 2 assert add(1, 2) != 2 >>> $ py.test ../tests/test_add.py =============================================================================== test session starts ================================================
ビヘイビア駆動開発 ― ウォーターフォールモデルからのステップ | POSTD
ビヘイビア駆動開発（BDD：Behavior-Driven Development、振る舞い駆動開発ともいう）を実務に沿って簡単に紹介し、ソフトウェア開発プロセスに対してこの手法がどれほど有益かを説明します。 はじめに BDDで重視しているのは、フィードバックループを最小限に短縮することです。BDDはソフトウェア開発手法の進化の中で、理論的に一歩前進したものといえます。本稿ではBDDの概念と、その原型のモデルを説明します。 ソフトウェア開発者や、エンジニア部門のマネージャー職に就いている人ならば恐らく、以下の図のようなウォーターフォールモデルはよくご存じでしょう。 注釈: Waterfall model：ウォーターフォールモデル System Requirements：システム要件定義 Software Requirements：ソフトウェア要件定義 Analysis：要求分析 Progr
薬物耐性を持つ多剤耐性菌「MRSA」に1000年前から伝わる薬が効果大という恐るべき事実が判明
ペニシリンの一種であるメチシリンなど、複数の抗生物質に対する薬物耐性を持つ多剤耐性菌が「メチシリン耐性黄色ブドウ球菌(MRSA)」です。健康な人には害のない細菌ですが、感染すると細菌を倒すための薬が効かなくなるという恐るべき細菌で、抗生物質を多用する病院などで多く見られます。そんなMRSAがなんと1000年前のまだ抗生物質が発見されていなかった時代の治療法で殺菌可能であることが発覚しました。 1,000-year-old onion and garlic eye remedy kills MRSA - BBC News http://www.bbc.com/news/uk-england-nottinghamshire-32117815 1000年前、アングロサクソン人が眼感染症の治療法として用いていた方法が、多剤耐性菌であるMRSAを殺菌するのに適切であることが判明しています。1000年
SSDにデータを書込みまくり再起不能に追い込む耐久試験で分かった信頼性に関する真実とは？
2013年からTech Reportが継続していた「SSD耐久試験」は、SSD主要6モデルに特別なプログラムを使って尋常ではない量のデータを書き込みまくって再起不能まで追い込むというもので、耐久性に不安を持たれがちなSSDの信頼性を判断するのに大いに役立つデータとして注目を集めています。そして、最後まで生き残ったモデルもついに息の根を止められ、1年半にわたって続けられたSSD耐久試験が完全に終了。そこからSSDの信頼性に関するおそるべき事実が明らかになっています。 The SSD Endurance Experiment: They're all dead - The Tech Report - Page 1 http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead ◆これまでのテスト経過
Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - Kentaro Kuribayashi's blog
著者のmizzyさんこと宮下剛輔氏よりご恵贈いただきました。ありがとうございます。 Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る さて、本書について、技術的な側面で語れるひとはたくさんいるだろうので、ちょっと趣向を変えて、エッセイ的な話を書く。ちょうど、著者も「本書は、単なるServerspecに関する解説書ではなく、Serverspecに関する思いを綴ったエッセイとも言えるかもしれません」(「はじめに」より)と書いていることだし。 Serverspec誕生の頃 約2年前の今頃、ある新しいシステムのためにサーバを構築しようとしていて、我々(mizzyさん、@lamanotramaさん、僕)は苦心していた。Puppetでサーバ構成を記述するに際して、もっといけ
xUTP Magazine - 第一回 xUnit Test Patterns の世界観
目的 はじめに テスティングパターンの一覧 パターンランゲージ 読み進めかた マーチン・ファウラーによる本書の構成の説明 私の読み方 原著者(Gerard Meszaros)による情報源 コミュニティによる情報源 さいごに この連載記事の目的は次のような感じです。 xUTP読書会で得られた知見を整理する xUnit Test Patterns に書かれている内容を分かりやすい形で広める 英語の壁も、難しさの壁も、読書会の有志による努力によって取り払われました。 軽い気持ちで、xUnit Test Patterns に挑戦してみましょう。 TDD にせよテストファーストにせよ、テストコードを書くのは近代的な開発では当然の行為です。 しかし、戦略の無いままに無数に書かれたテストコードは保守が難しかったり、 仕様変更によってプロダクトコードのみが修正されテストコードの修正は忘れられてしまうなど、
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
Androidの自動テストツール、今(2013年)から使うなら何がよいのか - kk_Atakaの日記
あらすじ Androidのテストを自動化したいので、テストツールの選定をしてみたが、昔の記事がヒットする事が多く、何を使えばいいのかよくわからん。 とはいっても、明確に「どんなテストがしたい」という方針もなく、とっかかりとしてどんなツールがあってどのくらい盛り上がってるのかが知りたかった。 環境 Windows 7 AndroidDeveloperTools Build: v21.1.0-569685 とりあえず Win メインで。 とっかかり ロジックまわりのテスト ロジック的なものは、 JUnit 拡張の TestCase クラスを使えば何とか書けそうというのはわかった。 Androidアプリ開発テスト入門（2）：Android SDKでビジネスロジックのテストを自動化するには (1/3) - ＠IT 2011 年の記事だけど、 JUnit で書くという大前提は崩れていないはず…。 画
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
