Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
Google App Engineの開発ではPythonを使います。GAEを使ったWebアプリの開発でテスト駆動開発を行う際にも,Python的なユニットテストの文脈を活用できます。 ただし,GAEでユニットテストを行うためにはいくつかのツールやトリックが必要です。ここでは,そのテクニックを簡単に紹介します。 その1 : NoseGAEを使う Pythonのテスト用ツールにNoseがあります。このツールは,複数のディレクトリを渡り歩いて,複数のテストコードを一気に実行してくれる便利なツールです。 NoseのプラグインNoseGAEをインストールすることで,GAEアプリのテストを楽に行うことができます。「nose --with-gae」というようにオプション指定をすることでNoseGAEを利用できます。NoseGAEでは,テストコード上でGAEのモジュールやパッケージをインポートするために必
ヱビスブログ :: ユーザストーリーから始めるTDD TDD from starting from user stories - a top-down styleを日本語でザックリまとめました。 意味を明らかに取り違えているようなところがありましたら指摘してください。 ------------- TDDのルールは最初にテストを書く事だ。現実世界のプロジェクトの多くは、ソフトウェアがGUI、Web、データベースや外部システムとの依存を含んでいる。大概これらはJUnitクックブックのサンプルほどシンプルではない。プロジェクトが異なれば、TDDの実装方法も異なる。例えばテスターが受け入れテスト記述の責務を取り、開発者はユニットテストを書く。TDDer向けにユーザストーリーから始めるトップダウンなTDDスタイルを提唱したい。 ユーザストーリーから始めるTDD What? ユーザスト
昨日はOSCに行ってきました。セミナーやブースはほとんど行かず、例によってRubyの会のあたりでだらだらしてたわけですが。 思いがけず師匠の師匠、id:t-wadaさんにもお会いできてびっくり。 で、そこでRailsとTDD(BDD)の話なんかしたので、一週間で思ったことをつらつらと。たぶん不正確というか、理解の足りないところもいろいろあるので、そのへんのツッコミをいただけると感謝です。 書いてたら長くなったのでagenda モデルのテストでは、とにかくロジックを書いたらテストを書く*1。def..endブロック(wを書いたら必ずテストもあるはず。 RailsのMVCコンポーネントの中では一番テストし易いので、そういう意味でもモデルを厚くすると幸せになりやすい。 コントローラのテストでは、基本的にリクエストを受けてから表示対象のオブジェクトを導出するまでをテストしたい。 ビューのテストでは
--INDEX-- アプリケーションのテスト Webアプリケーションを開発して実際に活用する前に、そのアプリケーションがちゃんと期待通りの動作をしているかという「テスト」を行う必要があります。 このテストを手動で行うと小さなバグを発見できなかったり、時間がかかったりとあまり良いことがありません。 Railsでは最初からテストを行うことを前提に開発を進められるように設計されています。 これから解説するテストを理解すれば、テストコードを先に書いてそれに合わせて開発を進めていくといった「テストファースト」と呼ばれる手法で開発することも出来ます。 では「テスト」について、STEP順に解説していきます。
近年のシステム開発では図1に示すように自動化されたテストを取り込み、継続的インテグレーションを実現した開発スタイルが提唱されています。 テストの自動化を導入することで、ソフトウェア開発で最も恐れるべき事象の1つであるデグレードを回避することができるため、積極的にコードを整理(リファクタリング)することができるようにもなります。 またテストの自動化は、先進的なアジャイル開発ではもちろんのこと、従来のウォーターフォール型開発プロセスにも有効的な適用が可能であるため、近年急速に一般化しつつあります。そしてRuby on Rails(以下、Rails)にはテストの自動化を実践するためのサポートが含まれています。
2 問題 テスト駆動開発(TDD)は今や広く受け入れられている。大企業は自社のプログラマに、多くのコストを掛けてTDDを教育している。カンファレンスでTDDは人気のトピックだ。アジャイル系はもちろん、それ以外でも。 TDDについての書籍も何冊か出版されている。筆者(Dave Astels)自身の著作はJolt awardを受賞した。では、何もかもがうまくいってると言えるのだろうか? TDDを実践している人々全てが、TDDについて深く理解し、TDDの恩恵を最大限に受けていると言えるのだろうか? んなこたぁない! TDDの本当の姿を正確に理解している人を私はごくわずかしか知らない。要するにTDD実践者の多くは、TDDの恩恵を最大限には受けていないのだ。何がまずいのだろうか? 2.1 テスティングが焦点 さて...なによりもまず、みんなTDDはテスティングだと考えている。TDDはそれだけ
テスト駆動開発(Test Driven Development:TDD)。最近この言葉を聞く機会が多いと思いますが、実際のプロジェクトでTDDを取り入れているというケースはあまり聞きません。本稿は、テスト駆動開発に興味はあるけれど、いまだ導入に踏み切れないという開発者のために、その効用や実際の運用方法について、具体例を交えながら述べたいと思います。前半はテスト駆動開発の意義と、導入に当たっての説得材料について検討します。後半では実際にテスト駆動開発を進めるに当たって具体的にやるべきことについて、事例を踏まえながら説明していきます。 テスト駆動開発(TDD)とは テスト駆動開発は一般にエクストリーム・プログラミング(XP)の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なもの
新しいソフトウェア開発技法へチャレンジできるか? ソフトウェア開発の世界にも日々の進歩がある。そしてその中には、使えばさまざまな恩恵を受けられる技法もある。しかし、それらを現場ですぐに活用できるとは限らない。例えば、1990年代末に生まれ、1つのブームを形成したエクストリーム・プログラミング(XP)という開発技法がある。これは、とても優れた開発技法だと思うのだが、開発プロジェクト単位で、顧客まで巻き込んだ形で使われることが前提となっている。しかし、顧客ぐるみでまったく新しい方法にチャレンジできるかといえば、できないことの方が圧倒的に多いだろう。では、エクストリーム・プログラミングの技法を全部使おうとせず、使うことができる部分だけを取り出して試みることができるかというと、そういうわけにもいかない。エクストリーム・プログラミングは、いくつかのプラクティスと呼ばれる項目から成り立っているのだが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く