You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
今日(2015-04-25)は福知山線の脱線事故から 10 年目の 4 月 25 日。つまり、まさーるさんこと石井勝さんが亡くなられてからも 10 年になる。 まさーるさんは、一言でいえば 1990 年代後半から 2000 年代前半の日本におけるオブジェクト指向プログラミング、自動テストとテスト駆動開発、そしてアジャイルソフトウェア開発の啓蒙において大きな役割を果たされた方だ。もしも 10 年前の福知山線に乗っていなければ、いまでも日本を代表するプログラマの一人だったのではないかと思う。 まさーるさんの残した足跡は、様々なところに見いだすことができる。 Java プログラマであれば、 Quick JUnit という Eclipse プラグインを使ったことがある方が多いのではないかと思う。 Quick JUnit はテストコードとテスト対象コードの間をショートカットで行き来できる便利なプラグ
こんにちは!開発の所(@ctokoro_me)です。 クラウドワークス勉強会「レガシーコード改善の戦略と戦術」前篇(戦略)に続き、後篇(戦術&懇親会)をお送りします。 「レガシーコード改善の戦略と戦術」 講師:和田 卓人(@t_wada) タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。 その後様々な縁に導かれソフトウェアパターンやXP(eXtremeProgramming)を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。 テスト駆動開発によって「完璧主義の呪い(完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念)」から解かれてからは、文章や講演、ハンズオンイベント等を通じてテスト駆動開発の啓蒙に努めている。 今日もグリーンバンド(テスト駆動開発者の証)を左手に着
こんにちは丸山@h13i32maruです。 ES6でアプリコード、テストコードを書いてテストをするための環境を作ったので、そのメモです。 目標 ES6で書いたアプリコードとテストコードをnpm run testでテストする 最終的な環境 最終的にはこんな環境になった。リポジトリ ECMAScript6 Google Chrome Travis CI npm traceur-compiler mocha espower-cli karma karma-cli karma-mocha karma-chrome-launcher bower power-assert 今回はgrunt/gulpのようなビルドシステムは入れていない。npm runをタスク実行のフロントとすることでタスク自体はお手軽にshで書いた。shだとwindowsが厳しいけど、まあとりあえず自分の環境用だしいいかなと。 以降で
本格的なテストを行うまえに 情報収集したものを備忘録として残しておきます。 外部サービス appium 名前から分かるとおりseleniumのようなテスト自動をアプリで行うことが可能。必要条件は「Mac OSX 10.7以上、XCode 4.5以上 」となっているがSwiftも対応しているかは実際にコードを書かないとわからない。 saucelabs https://saucelabs.com/ seleniumやappiumのテストを高速実行。実行時のビデオも残してくれる。 Remote Test Kit リモートによる実機テストができる。 機種依存ポイントとなるセンサ周りのテストがしづらいのは残念。 OSS Quick Swiftが発表された2日後にGithubにコミットされた、世界で一番最初のSwiftのテストフレームワーク。RSpec, Specta, Ginkgoの影響を受けている
本記事はGo Advent Calendar 2014の18日目の記事です. Go言語は,クロスコンパイルや配布のしやすさからコマンドラインツールの作成に採用されることが多い.自分もGo言語でいくつかのコマンドラインツールを作成してきた.例えば,GitHub Releaseへのツールのアップロードを簡単に行うghrというコマンドラインツールを開発をしている. コマンドラインツールをつくるときもテストは重要である.Go言語では標準テストパッケージだけで十分なテストを書くことができる.しかし,コマンドラインツールは標準出力や標準入力といったI/O処理が多く発生する.そのテスト,例えばある引数を受けたらこの出力を返し,この終了ステータスで終了するといったテストは,ちゃんとした手法が確立されているわけではなく,迷うことが多い(少なくとも自分は結構悩んだ). 本記事では,いくつかのOSSツール(得に
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか?」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか? 私が何かを見逃したのでしょうか? 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。
Test Anything Protocol Perlは非常にテストを重視している言語です。連載第14回ではPerl本体のテスト数がどのように推移してきたかを、また連載第24回ではCPANモジュールの品質保証に大きな役割を果たしてきたCPANTSについて簡単に紹介しましたが、Perlとテストのつながりはそれだけではありません。CPANにはTestを名前に含むディストリビューションが500以上もあがっていますし(これは全ディストリビューション数の約2.5%にあたります)、Perlで標準的に使われているテスト形式はTest Anything Protocol (TAP)という名前を得て多くの言語に移植され、2008年からはIETFの標準化を目指した活動も始まっています――というと何やらすごいプロトコルのように聞こえるかもしれませんが、Test Anything Protocolというのは要
第5章ビジネス視点の改善~効果検証に基づく機能改善と、チームでの仕事の進め方 安宅啓 2014-02-21
いまさら聞けないTDD/BDD超入門(4): 開発現場で保守性の高いTDD/BDDを実現するための3つのポイント――テストレベル/網羅性とは 開発現場でTDD/BDDを導入するためのポイントを大きく三つに分けて解説。テストレベルや網羅性、サイクルタイムについても紹介します。(2014/10/17) いまさら聞けないTDD/BDD超入門(3): TDD/BDDにおける「振る舞い」の意味するところとは何なのか BDD初心者が持ちがちな3大疑問点を提示して、さまざまな角度からそれを明らかにしつつ、振る舞いを表現する2つのテクニックを紹介する。(2014/4/30) いまさら聞けないTDD/BDD超入門(2): TDD/BDDの思想とテスティングフレームワークの関係を整理しよう TDD/BDDの思想に触れ、フレームワークとしてxUnit、JBehave、xSpec、Cucumber、Turnip、
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
開発現場で保守性の高いTDD/BDDを実現するための3つのポイント――テストレベル/網羅性とは:いまさら聞けないTDD/BDD超入門(4)(1/3 ページ) 連載目次 前回の『TDD/BDDにおける「振る舞い』の意味するところとは何なのか」までで述べたような、TDD/BDDを導入するときには、現場で「で、今までやってきた単体テストと結合テストって、どうやってこれに組み込めばいいんだっけ?」「網羅的なテストをどうやって書けばいいんだろうか?」「テストを先に書くだけくらいにしか違いがないのではないだろうか?」などの疑問が出てきます。 今回は、これらの導入時の疑問を解決するようなパターンを紹介します。まずは説明のためにいくつかの言葉の定義を紹介してから、どういったことで保守性の高いTDD/BDDを実現できるかを紹介します。 テストレベルの定義 大まかに言えば、「テストレベル」とはテスト対象の大き
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く