RSpec: Overview
Take very small stepsDon’t rush ahead with more code. Instead, add another example and let it guide you to what you have to do next. And don’t forget to take time to refactor your code before it gets messy. You should keep your code clean at every step of the way. View Documentation The BookEffective Testing with RSpec 3: Build Ruby Apps with ConfidenceThis definitive guide from RSpec’s lead devel
たった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 ================================================
テストコードとか書いてみてもいいんじゃない？ - Qiita
from dog_bark import dog_bark def test_dog_bark(): assert u'ワンワン！' == dog_bark('Japan') assert u'Bow wow！' == dog_bark('USA') となります。 実際にdog_bark関数を実行して、想定した結果文字列と直接比較するというコードです。 世に言うテストコード書こうぜ！という主張はこんな感じのコードを量産しようぜ！ ということになります。特に難しいことはないですね。 テスト実行は例えばPythonのPytestなら $ py.test test_dog_bark.py でOKです。もしテスト関数を増やしたとしても勝手にファイル内のテストを認識して 実行してくれます。 ちなみにどの言語のどのテストフレームワークもこのくらいの機能はあります。 (コンパイルがいる言語は多少手間が増
[Perl] 作成したモジュールをCPANで公開する手順
久しぶりに Perl モジュールを作成してみた ので、せっかくなので CPAN にアップロードしてみました、の手順をメモ。 もともと、2002年に CPAN へのアップロードサイト PAUSE 用のアカウントは 作ってあったけど、実際に自作モジュールを CPAN で公開してもらったことはなかったので、 実は今回が初挑戦でした。 もし↓に間違っている点がありましたら、ご指摘いただけると幸いです。＞識者の方 配布用のモジュールを作成する まず第一歩は、 perlnewmod - 新しいモジュールを配布するには を熟読すること。 モジュール .pm ファイルと、 そのアーカイブ .tar.gz ファイル を作成するのが最初です。 中身は以下のようなファイル構成になりました。 lib/XML/TreePP.pm # Perlモジュール本体 Makefile.PL # ほぼh2xsで生成したそのまま
Test Yourself - テストを書くと何がどう変わるか
SideCI主催のVenturesCI.rb #1のLT資料です。 「どうやらテスト駆動型開発は死んだようです。これからのCI」です。 要約すると、TDD死んじゃった。テスト自体は否定しないし有用だと思う。でも、ユーザに触れるEndToEndの振る舞いのテストを主に書き、テストカバレッジ100%を目指す時代は終わった(コストが高過ぎる。自転車の補助輪のようなものだ、テスト駆動型はもう外そう！)。EndToEndテストはCapybaraがよさそうだね。という内容です。
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織にテストを書く文化を根付かせる戦略と戦術
Cake php + php unitによる実践的ユニットテスト