SimpleCov: A Powerful, Straightforward Ruby 1.9 Code Coverage Tool
Ruby Weekly is a weekly newsletter covering the latest Ruby and Rails news. SimpleCov is a code coverage analysis tool for Ruby 1.9. It uses 1.9’s built-in Coverage library to gather code coverage data, but makes processing it’s results much easier by providing a clean API to filter, group, merge, format and display those results, thus giving you a complete code coverage suite with just a couple l
RSpec で parameterized test を簡単に書ける、rspec-parameterized を作成しました - tomykaira makes love with codes
rspec-parameterized | RubyGems.org | your community gem host tomykaira/rspec-parameterized次のような spec が書けます。 describe "plus" do where(:a, :b, :answer) do [ [1 , 2 , 3], [5 , 8 , 13], [0 , 0 , 0] ] end with_them do it "should do additions" do (a + b).should == answer end end with_them :pending do it "should do additions" do (a + b).should == answer end end end -fd をつけて実行すると次のような感じで出力されます。 RSpec::Pa
Pythonのunittestモジュールのほんとにちょっとしたtips - darwiniaの日記
だれかが書いてそうだけど、Pythonのunittestモジュールのtipsをめも。 私はほとんど以下のようにunittest.main()しか使わないのですが、 ユニットテスト実行時にオプションを指定することで、個別にユニットテストが実行できるみたい。 ということに今頃気づきました。 if __name__ == "__main__": unittest.main() まず、"-h"オプションでUsageが表示されます。 $ python pyramidTest.py -h Usage: pyramidTest.py [options] [test] [...] Options: -h, --help Show this message -v, --verbose Verbose output -q, --quiet Minimal output Examples: pyramidTes
Web プログラミングってこんな感じじゃなかろうか - 偏見プログラマの語り！
この歳になって初めて Web プログラミングの現場を見て、刺激的な毎日を送らせていただいています。さて、仕事をしていて一番強く感じるのは前職での開発（スタンドアロンパッケージソフト開発をしていた会社の文化）との違いです。で、Web 開発とは何たるかを表現したくて悶々としていたのですが、ある程度整理ができてきたので文章にしてみようと思います。僕はアカデミックな話よりも現場の話をしたいので、いくつもレイヤをまたいだ文章になります。そのため本稿では具体的な技術の詳説とかアジャイル的な用語が飛び交う説明とかはありません。そういうのを期待している人は読まないでください。 ・Web に限らず、お仕事プログラミング全般で共通のこと プログラムを知らない人がイメージする開発というものは、粘度をこねたりくっつけたりするような作業じゃないでしょうか。つまりそれは、知識さえあれば難しいものではなく、モチベーショ
coverage
Coverage.py measures code coverage, typically during test execution. It uses the code analysis tools and tracing hooks provided in the Python standard library to determine which lines are executable, and which have been executed. Coverage.py runs on these versions of Python: Python 3.8 through 3.12, and 3.13.0rc1, including free-threading. PyPy3 versions 3.8 through 3.10. Documentation is on Read
Python用のユニットテストツールまとめ — TRIVIAL TECHNOLOGIES 2.0
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー みなさんテストしてますか？ Pythonには沢山の便利でステキなテストツールがあります。標準ライブラリに入っているunittestやアジャイルドキュメンテーションとも呼ばれるdoctestなど，標準の機能だけでもかなり強力なのですが，外部のツールを使うとより快適なテストライフが送れるのです。 python.orgにあるPython testing tools taxonomy(Python用テストツールのまとめ)というページがあり，ここに有益な情報が集まっているので例によって超訳してみました(ユニットテスト関連のみ)。 ツール カテゴリ 作者 ツールが含まれるフレームワークなど 特徴
何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops
テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても本当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定
Gradle Build Tool
Gradle Build Tool accelerates developer productivity Gradle is the open source build system of choice for Java, Android, and Kotlin developers. From mobile apps to microservices, from small startups to big enterprises, it helps teams deliver better software, faster. Build Anything Write in Java, Kotlin, C++, or any language of your choice. Package for deployment on any platform. Go monorepo or mul
Vows « Asynchronous BDD for Node
Asynchronous behaviour driven development for Node. 非同期にテストしたい理由は二つある。 一つめは、自明な理由だが、node.jsが非同期だから、その上で走るテストも非同期であるべきだ。 二つめは、I/Oを並列化することによって、高速に動作するテストを作るためだ。 vowを書いて、実行しよう: $ vows test/* --spec テストレポートで、思ったとおりに動いていることを確かめよう。 A non-promise return value ✓ should be converted to a promise A topic not emitting an error ✓ should pass null if the test is expecting an error ✓ should pass the result othe
みゆっき☆Think 第10回 「チーム開発 ～脱ぼっちマインド～」 - ドワンゴ 研究開発ブログ
こんにちは。ドワンゴの荒木です。 弊社若手エンジニア鳥居みゆっきと一緒に技術を学ぶ生放送「みゆっき☆Think」！ 第10回のテーマは「チーム開発 ～脱ぼっちマインド～」 放送内で使用されたスライドと、みゆっきノートを公開します。 放送内で使用された資料はこちら↓ みゆっき☆Think#10 チーム開発〜脱ぼっちマインド〜 View more presentations from akitsukada みゆっきノートは、みゆっきが期末テスト中のためアップロードを延期しています。 しばらくお待ち下さい。 > 放送を見逃された方は、 チャンネルのアーカイブ動画 で視聴いただけますので、是非ご覧下さい！ 第11回みゆっき☆Thinkは年始のお休みの都合により、1/13（金）夜7時からの放送を予定しております。 是非、次回もご覧下さい！
List of unit testing frameworks - Wikipedia
2.48 OpenEdge Advanced Business Language (ABL), Progress 4GL
開発するのに30分、テストするのに10万年
このように解説すると、「C2網羅を100％実施するのは難しいかもしれないけれど、C0カバレッジは簡単じゃないか！」「これなら、すぐにできそうだ!!」「最低限、C0は100％網羅しなきゃね」などと考える人がたくさんいます。しかし、実際には、そう単純ではありません……。 プログラマは本能的に、「作成したソース・コードは、最低1回は実行してみないと、正しく動作するか不安だ」と考えます。確かにそのとおりで、エンド・ユーザーにしてみれば、1回もテストしていない機能は恐ろしくて使いたくもありません。これが、C0網羅の根底にある考え方です。 しかし、最も緩い基準といえるC0網羅でさえ、実際は簡単ではありません。その理由を以下に挙げていきます。 理由1：パス網羅ツールなしにパス・カバレージは不可能 簡単なプログラムであれば、ソース・コードを印刷して、通過したパスに色を付ければ、パスの網羅状況がすぐに分かり
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門：ユカイ、ツーカイ、カイハツ環境！（21）（1/4 ページ） CIツール「Hudson」改め「Jenkins」とは 「Jenkins」とは、CI（継続的インテグレーション）ツールとして有名な「Hudson」の開発者たちにより開発されているCIツールです。Hudsonは商標上などの問題によりJenkinsと名前を変えて継続することが発表されたので、記憶に残っている方も多いと思います。現在では落ち着いて開発されているようです。 本稿では、今話題のJenkinsの使い方を紹介します。本記事の想定読者は、Java開発を行っている方で、「今までCIを導入していなかったけどこれから導入しよう」「Jenkins（Hudson）は使えそうだけど、難しそうだなぁ」と思っている方を対象としています。本稿を読めば、10分程度でJe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
