Test::Unit と RSpec と Shoulda
昨日の記事 続・Rails 3.x 時代のテストフレームワーク では、Rails で使用できるテストフレームワークの基礎知識と相互関係についてまとめました。 今日は、Test::Unit と RSpec と Shoulda を具体的に比較してみたいと思います（Cucumber については、別の機会に…）。 例として「変数 @total に文字列 '100' をセットすると、式 @total.to_i は 100 を返す」というテストケースを考えましょう。 純粋な Test::Unit ではこのように書きます。 require 'test/unit' class SimpleTest < Test::Unit::TestCase def test_should_return_100 @total = '100' assert_equal(100, @total.to_i) end end R
tox と pytest で Python 2/3 両対応のテストを実行する - forest book
pytest *1 に関連して tox も一緒に覚えておくと良さそうです。 @t2y @methane 少し前からtox + py.test が鉄板な気がしますねえ 2012-02-07 20:50:23 via twicca to @t2y tox については id:Ehren の入門記事が分かりやすいです。 Pythonでのテストツールtox入門 - Keep on moving 複数の Python バージョン毎に virtualenv で仮想環境を作成して、そこに自分のパッケージと必要なライブラリ等をインストールして、それぞれのバージョン毎にテストをまとめて実行してくれます。例えば、Python 2/3 の両対応を考えたときに、自分で環境を切り分ける手間隙を軽減できて、かなり便利です。ここで言う Python 2/3 両対応は 2.6/2.7 と 3.x の対応を指します *2 。
oreilly.com
More than 5,000 organizations trust O’Reilly to help their teams learn the technologies of today—and be ready for what’s next. We can help yours too. It’s time to upskill your teams to leverage generative AI LLMs aren’t just the future of work—they’re the now. Learning to use large language models is vital for every business and every knowledge worker. O’Reilly has all the resources your team need
enchantMOONでTDDしようぜ - _development,
概要 enchantMOONでTDDする方法を解説します。 以下の効能があります。 PCで編集したファイルをenchantMOONで即実行できる つまり編集するたびにストレージをマウント・アンマウントしなくていい もちろんZipに固めたりアップロードしたり台帳を開いたりしなくてもいい 但し、最終的にプログラムをシールとして実行・配布したい場合は従来通りマウントして書き込むかZipで固めて本体に転送する必要があります。 本エントリは「WEBコンソールでenchantMOONをスクリプティングする」の応用編です。enchantMOONとPCとの通信にはSocket.IOを使います。 QUnit 本エントリでは、テストフレームワークとしてQUnitを使います。 Jasmineじゃないの？と思われるかもしれませんが、最初は簡素なフレームワークを使ったほうが実現しやすかろうというのがQUnitを使っ
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
Python で TDD してみる - methaneのブログ
RSpec の入門とその一歩先へ がとてもよい記事だったので、 Python で写経させてもらいました。 https://github.com/methane/pytest-tut Ruby コミュニティと Python コミュニティの考え方の違いも見えて面白いと思います。 環境は Python 3.3 で、実行には py.test コマンドを使いましたが、 py.test の機能は特に使っていないので nose でもなんでも大丈夫です。 ファイルの作成 まずは空の実装とテストを作ります。 message_filter.py class MessageFilter: pass message_filter_test.py 最初のテストを書く py.test は .should といったメソッドを勝手に生やしたりはしません。普通に assert 文を書きましょう。 --- a/messege
うさみみエンジニアが2012年に買った技術書 - うさぎ組
追加 2013/01/01 ここから 僕の読書方法Togetter 【うさみみさんの本の読み方 - Togetterまとめ】 (2012年の【僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組】のときに「どのように読書しているか」への質問ツイートへの返答をまとめたもの) 追加 2013/01/01 ここまで なんかTwitterでつぶやいたら気になるとの事だったのでのっけてみます。 （個人的には他人のが気になるので、これを見た人が自分のを公開してくれるとうれしい とりあえず、新しく買ったり、借りたりして読んだ技術書は全部のっけます。 2011年に既に買っているものは省いています。 その中でもいいなって思ったのは前半で括りだしてみました。 「いいな」っていうのは「今の自分にぴったりだったな」っていう意味で良書かどうかはまた別かもね。 うさみみ的によかった新しく読んだ書籍たち
テスト駆動型設計 - モックとテストを使用して役割に基づいたオブジェクトを設計する
June 2009 Volume 24 Number 06 テスト駆動型設計 - モックとテストを使用して役割に基づいたオブジェクトを設計する Isaiah Perumalla | June 2009 コードは MSDN コード ギャラリーからダウンロードできます。 オンラインでのコードの参照 目次 実装ではなく対話が中心 バーコードを読み取る 役割を見極める 販売を完了する 相互のやり取りを抽象化する 領収金額を計算する 商品の説明を取得する リファクタリング まとめ テスト駆動開発 (TDD: Test Driven Development) の世界には、モック オブジェクトを使用した技法が存在します。オブジェクトの内部構造ではなく、むしろ、オブジェクトどうしの相互関係に注目することによって、特定のシステム内でオブジェクトが果たす役割を見極めるために、モック オブジェクトが役立ちます。
軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ
これは、TDD Advent Calendar jp:2012 の16日目のエントリーです。前日のエントリーは、@pocketberserkerさんの「Specs2のParameterized Testのはなし」でした。 ご存じの方も多くなっていると思いますが、「テスト駆動開発（以下、TDD）」とはテストコードを先に書くテストファーストを基盤とした開発手法です。先にテストコードを書く事により、これからどのようなプロダクションコードを書こうとしているかを明確にすることができることが特徴です。このため、テストの技法というようりは設計の技法です。 テスト駆動開発を実践することにより多くのメリットを得ることができます。このことは2011年のAdvent Calendarで言及しました（TDDを学ぶべき10の理由 #TddAdventJp）。TDDは簡単に導入することができる一方で、実践するのは非常
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
