保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
画像周りの動作が意味不明かつ使い辛いので移転しました。 go言語のテスティングフレームワークについて — さにあらず
先週初めてGo言語を触る機会があったので、テストの書き方を調べた。 要約すると、標準ライブラリのtestingが好きになれず他に調べても気に入ったものが見付からなかったので自分でつくった。 testing Go言語にはtestingという標準ライブラリが用意されていて、 「go test」コマンドを実行すると「*_test.go」という名前のテスト用ファイルがそれぞれ実行される。 具体的には、そのファイル内で定義されたTest*という名前のテスト用関数がそれぞれ実行されるようになっている。 公式サイトの例ではこういうコードが紹介されていた。 type doubleTest struct { in, out int } var doubleTests = []doubleTest{ doubleTest{1, 2}, doubleTest{2, 4}, doubleTest{-5, -10}
SlimerJSはWindows/Mac OSX/Linux用のオープンソース・ソフトウェア（Mozilla Public License）です。 スクレイピングをしたり、テスト自動化を行う際に役立つのがPhantomJSですが、ブラウザはWebKitベースです。今回はGeckoベースのSlimerJSを紹介します。 実行した場合です。スクリプトを書いてSlimerJSに渡します。 Geckoベースのブラウザが立ち上がってテストが実行されます。 MOONGIFTもちゃんと表示されます。 ログも表示されます。 SlimerJSはスタンドアローン版でWindows/Mac OSX/Linux向けのバイナリも提供されています。XULRunnerを使って実行もできますので、使いやすい方を選択すれば良いでしょう。Geckoエンジンを使った自動処理に便利です。 MOONGIFTはこう見る 今はHTML
ウェブアプリケーションのJSのテストするのにCasperJS使ったら便利だった． CasperJSはPhantomJSにテスト用ユーティリティがついて便利になったやつ． JS，MVCできれいに書いてると，Modelの単体テストとかできるけど，昔ながらの感じだと，ここをクリックしたらこれが表示されること，みたいなテストを書くことになる．けどライブラリとかいろいろあってどれを使えばよいか分からなくて敷居が高い．CasperJSを使ったらこれだけで完結してテスト書ける． PhantomJSは単なるブラウザだけど，CasperJSはテストのフレームワークとか，DOMのテスト関数とかがついてる． 非同期なタスクの実行の仕組みも入ってて，casper.thenっていうのを順番に書いていくと，順番に呼んでくれて，click()して，casper.thenしたら，ページ遷移したら次のページに移動してる．ス
PHPプロダクトのテストで、Harriet+Test::mysqldをつかいはじめたのですが、題名でちょっと困ってたら、Yancha*1でhide_o_55さんがコードを読んで解決策を教えてくれたのでブログにします！ありがとうございました！！ そのまえに… ググったりドキュメントにかいてなかったとしても、コードを読もう！！！ Test::mysqldとは require Test::mysqld; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '', # no TCP socket } ) or die $Test::mysqld::errstr; print $mysqld->dsn; #DBI:mysql:dbname=test;mysql_socket=/path/to/tmp/mysql.sock;
https://github.com/tokuhirom/Harriet/ https://metacpan.org/module/TOKUHIROM/Harriet-0.01/lib/Harriet.pm テストのときにつかう mysqld, memcached, stf, groonga あたりのデーモンを、.t 単位で起動していては遅くてかなわない。かといって、あらかじめ起動させておくというのも。。 というわけで prove のプラグインとしてよしなにする、みたいなのをがんばってかく、というような試みがおこなわれてきたわけですが、どうもめんどくさい。 なんか適当にやったらうまくうごく、っていうかんじのカジュアルなツールがほしいな、なんておもったりするわけですよ そこで、Harriet ってのをつくってみました。 なんかこう、t/harriet/mysqld.pl っていうファイル名で
RSpec の書き方について 要約:RSpec は単なるテストを英語っぽく書けるツールではなく開発の全プロセスを加速するツールであるのでプロジェクト初期から有効に利用する必要がある。 4/1 ですが気にせず真面目な話を書きます。 RSpec は多分 Ruby 界隈で一番使われているテストフレームワークの一つだと思います。であるので使い方の解説や概念の解説多いですが、個人的にはそれらの解説は的を外したものが多いと考えています。 RSpec の真髄を会得するには、 RSpec の spec をどのように書くかということを考えてゆく必要があると思います。 まず RSpec の特徴的な点とはなんでしょうか。 RSpec でテストは以下のように書かれます。 describe "肛門" do context "排便する時" do it "高速に排便されると肛門がすりきれる" do 肛門がすりきれるとい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く